/irc-logs / w3c / #html-wg / 2007-03-28 / end

Options:

# Session Start: Wed Mar 28 00:00:00 2007
# Session Ident: #html-wg
# [00:28] <Hixie> DanC?
# [00:29] <DanC> yes? (I usually like to know what the question is when I'm pinged)
# [00:29] <Hixie> hey dude
# [00:30] <Hixie> just wondering if you knew if we were going to have a telecon yet, and whether you had an agenda for it in the works at all
# [00:30] <DanC> still leaning towards it, but teetering a bit now and then.
# [00:30] * Hixie needs to prepare for the telecon if we have one, but is in a meeting all day tomorrow and the meeting would be the morning of hte next day
# [00:31] <DanC> latest info is that dbaron gave availability info
# [00:32] <DanC> ew. so you need an agenda more than 24 hours in advance.
# [00:32] * Parts: hasather (hasather@81.235.209.174)
# [00:32] <Hixie> ideally
# [00:32] <Hixie> if possible
# [00:32] <DanC> and I'm due for family time in 30 minutes
# [00:32] <Hixie> if you can get one early on tomorrow that would work too
# [00:33] <Hixie> really it need about 12 hours notice, since i'll be sleeping for 8 of those hours :-)
# [00:33] <DanC> if you have 10 minutes now, maybe I could bounce some ideas off you and get it done... let's see...
# [00:33] <Hixie> s/it/i/
# [00:33] * Joins: Zakim (rrs-bridgg@128.30.52.30)
# [00:33] <Hixie> sure
# [00:34] <DanC> agenda + introduction to W3C teleconference tools, Zakim, RRSAgent (20 to 30 minuntes, timed; optional for those that have been to a W3C telcon before)
# [00:34] * Zakim notes agendum 1 added
# [00:34] <DanC> agenda + Convene, take roll, review agenda
# [00:34] * Zakim notes agendum 2 added
# [00:34] <DanC> hmm... then the order gets less clear... Zakim will let us re-order them, so don't put too much stock in the order yet...
# [00:35] <DanC> agenda + Proposed Design Principles
# [00:35] * Zakim notes agendum 3 added
# [00:35] <DanC> agenda + HTML5 review
# [00:35] * Zakim notes agendum 4 added
# [00:35] <DanC> agenda + HTML WG hosting offers: XTech/Paris/May? SFO/June?
# [00:35] * Zakim notes agendum 5 added
# [00:36] <DanC> agenda + regular teleconference slot? (only if I get around to preparing a survey before the call)
# [00:36] * Zakim notes agendum 6 added
# [00:36] <DanC> I'm not sure discussion of both HTML5 review and WF2 will fit in one telcon.
# [00:38] <Hixie> i'm not sure what most of those items mean
# [00:38] <DanC> the goal of the HTML5 review would be to get a few people to take action items to review the spec, or perhaps parts of it...
# [00:38] <Hixie> wouldn't we want everyone who's interested to do it?
# [00:38] <Hixie> why would that need a telecon?
# [00:38] <DanC> it doesn't necessarily need a telcon, but...
# [00:39] <Hixie> let me rephrase that
# [00:39] <DanC> ... (a) the discussion is easier to follow if a few people are nominated to lead it...
# [00:39] <Hixie> why would getting volunteers from a telecon be better than getting them by e-mail
# [00:39] <DanC> and (b) there's an anybody/somebody/nobody risk, and action items are a good way to manage it
# [00:40] <DanC> if you agree to something by email, there's little consequence to not doing it.
# [00:40] <Hixie> i'm not convinced there's any consequence to agreeing to it by phone either. but ok.
# [00:40] <Hixie> it would be nice to have this agenda sent to the list, with the various things i mentioned in my mail filled in for each one
# [00:41] <DanC> most people feel pretty uncomfortable showing up to a teleconference empty-handed after they've promised to do something. At least: that's the way I'm used to getting groups to complete work.
# [00:41] <DanC> yes, the agenda has to get sent to the list. let's return to your list of questions...
# [00:41] <Hixie> wow, i wish the csswg was like that
# [00:41] <Hixie> (every telecon people always turn up having not done their action items. same with the waf and other groups i'm in.)
# [00:42] <DanC> umm... I take that sort of thing pretty seriously. If you agree to do something and then don't do it, I expect some explanation, and I don't let it go unnoticed.
# [00:42] <Hixie> fair enough.
# [00:42] <dbaron> I'm in the same all day meeting today and tomorrow and Hixie. (CSS f2f)
# [00:43] <Hixie> s/and H/as H/
# [00:43] <dbaron> yeah
# [00:43] * Quits: heycam (cam@203.214.81.60) (Ping timeout)
# [00:44] <DanC> I'm aware that some groups have a pattern of action items with no progress week after week. that's no way to run a group, IMO.
# [00:44] <Hixie> no disagreement from me there
# [00:44] <DanC> if you don't get it done, I find somebody who will, or we decide together that it's not worth doing, or something.
# [00:44] <dbaron> but if I do my CSS action items somebody will block the draft from being published, so why bother?
# [00:44] <Hixie> danc: sorry if i sound too negative, i'm just too used to meetings that are wastes of time, i'll try to give yours a chance :-)
# [00:45] <DanC> excellent. that's all I ask.
# [00:45] <Hixie> DanC: would be nice to see the information for the items i mentioned in that mail for each action item, though, i think that would go a long way towards determining if the meetings are being a success
# [00:46] <DanC> "What problem the meeting is supposed to be fixing" ... (a) we have agreed to produce an HTML spec, and we don't have one yet. further, many of us are not clear on which end of this WG is up, or where it's going.
# [00:46] <DanC> [read (b) for "further" there, perhaps]
# [00:47] <DanC> "Why e-mail has failed to solve the issue, why a meeting is expected to solve the problem better". voice has all sorts of subtle clues that text doesn't give. whether somebody hesitates or not can say a lot.
# [00:47] <DanC> also, a straw poll can be done in a few seconds rather than a few days
# [00:48] <Hixie> i meant those questions to be specific to the issues raised
# [00:48] <Hixie> to the agenda items, i mean
# [00:48] <Hixie> as opposed to general comparisons of audioconference vs e-mail vs irc, where each has pros and cons
# [00:48] <DanC> hmm... so 5 questions per agendum? hmm...
# [00:49] <Hixie> well the answers would be different for each item, yeah
# [00:50] <DanC> this order is getting taller... not unreasonable, but you're also asking for expedited service.
# [00:50] <DanC> and we just used 20 of my 30 minutes. hm.
# [00:51] <Hixie> well items 1 and 2 seem to have obvious answers
# [00:51] <Hixie> it's items 3 and 4 that are the "work" items
# [00:51] <DanC> the biggest problem I see with trying to evaluate whether the meeting is a success is that there's no way to measure it. There's no way to answer "how productive would the WG have been had we not had the meeting?"
# [00:52] <Hixie> (items 5 and 6 being just about future meetings, which presumably would have the same process of going through these steps)
# [00:52] <DanC> This is management, not engineering. I make up an answer, and we find out much later whether it's a good one.
# [00:52] * Joins: tylerr (tylerr@66.195.32.2)
# [00:52] <Hixie> well, for example, something like:
# [00:52] <Hixie> "if someone has volunteered to organise and lead an effort to review the html5 group with a deadline, then the meeting was a success"
# [00:53] <Hixie> might be a good answer for your "html5 review" item
# [00:53] <Hixie> based on what you said earlier
# [00:53] <mjs> s/group/spec/
# [00:53] <DanC> ah... but that requires that I tip my hand...
# [00:53] <Hixie> er yes
# [00:53] <Hixie> DanC: ?
# [00:53] <Hixie> DanC: i think it would be helpful if we were open, yes :-)
# [00:54] <mjs> unfortunately, having an agenda is incompatible with having a hidden agenda, if you want to measure whether useful progress was made on teh agenda
# [00:54] <DanC> when you're recruiting people to do work, sometimes it's best to let them offer before you ask in so many words.
# [00:55] <Hixie> well you don't have to ask, but we still have to be clear about what the intent is
# [00:55] <mjs> I think reviewing might be premature without understanding what output is expected from the review or what decisions, if any, we would base on it
# [00:55] <Hixie> yeah
# [00:55] <mjs> so I would not volunteer to lead it
# [00:55] <DanC> I'll keep that in mind. but I also ask that to some extent, you trust me to do what, in my experience, is effective.
# [00:55] <mjs> because I wouldn't know what my deliverable would be
# [00:56] <DanC> yes, review might well be premature. that's why I want to discuss it by phone in a group setting... to get a feel for what people are comfortable with.
# [00:56] <Hixie> DanC: hey, you're not trusting what i think is effective ;-)
# [00:57] <DanC> no?
# [00:57] <Hixie> well, you want a telecon :-)
# [00:57] <DanC> that doesn't mean I don't trust you to be effective by email/irc/etc.
# [00:58] <mjs> I have found all the w3c telecons I've attended to be a frustrating mess, but I'm willing to give it a shot
# [00:58] <Hixie> danc: i was just teasing
# [00:58] * DanC is a little depressed to hear that w3c is wasting so much of people's time...
# [00:59] <DanC> I think that's the #1 job of a chair: to make sure people feel their time was well spent.
# [00:59] <Hixie> DanC: but still, i would appreciate it if you could send the information i listed tomorrow or something, at least for the agenda items that you'd like myself and others to attend (as opposed to #1, e.g., which would just be a tutorial for newbies, as it were)
# [00:59] <DanC> yes, I'm going to try, Hixie
# [01:00] <Hixie> cool, thanks
# [01:00] <DanC> is there some particular time of day that makes a difference?
# [01:00] <DanC> as far as when the agenda comes out?
# [01:00] <DanC> I'm aiming for T-24 hours, but you said something about "early in the day" or something
# [01:01] <Hixie> earlier is better, 6pm PDT is when i go offline and won't be back online before the meeting probably
# [01:01] <DanC> oh. T-24hrs comes before 6pm PDT
# [01:01] <DanC> speaking of T...
# [01:02] <Hixie> yeah, that's about T-12 or so
# [01:02] <DanC> it's family time.
# [01:02] * DanC is away: family time
# [01:02] <Hixie> later
# [01:02] * Quits: mjs (mjs@17.255.97.200) (Quit: mjs)
# [01:08] * Joins: mjs (mjs@17.255.97.200)
# [01:19] * Joins: Lachy_ (chatzilla@220.245.91.147)
# [01:26] * Joins: asbjornu (asbjorn@84.48.116.134)
# [01:41] <Lachy_> marcos_ or marcos__, yt?
# [01:41] <marcos__> yep
# [01:42] <marcos__> still here...
# [01:57] <Dashiva> It's a bit messy when replies arrive with Date: headers indicating they were sent before the original message
# [02:00] <h3h> careless mail clients?
# [02:00] <Lachy_> some people just don't set their computer clock properly
# [02:01] <h3h> fair enough. though it seems like that should be decreasing with auto time-syncing in Windows and OS X
# [02:01] <Lachy_> and in Linux, I believe
# [02:01] <h3h> depends on the flavor :)
# [02:02] <Lachy_> Ubuntu does, that's all that matters :-)
# [02:02] <h3h> hah.
# [02:03] <Dashiva> Look at VisibleMailData and the reply
# [02:03] <Dashiva> One of them seems to have forgotten DST
# [02:03] <h3h> I hate DST
# [02:03] <Lachy_> few people like it
# [02:04] <Lachy_> I hate it, it screws everything up
# [02:04] <Dashiva> Lachy_: Looked at the PeopleLocations page recently? Would be nice to get a confirmation Australia is correct now
# [02:05] <Lachy_> I edited it last, so it's correct
# [02:05] <Lachy_> unless someone changed it back...
# [02:05] <h3h> people keep adding themselves without paying attention to the order
# [02:05] <Lachy_> good, still says (UTC+11 summer, southern hemishpere)
# [02:05] <h3h> makes me itch
# [02:07] <Lachy_> it'd be cool to have a google map with markers for everyones location, and that also indicated the time zone.
# [02:08] * Quits: tylerr (tylerr@66.195.32.2) (Quit: Leaving)
# [02:08] <Hixie> Zakim, who's here?
# [02:08] <Zakim> sorry, Hixie, I don't know what conference this is
# [02:08] <Zakim> On IRC I see asbjornu, Lachy_, mjs, Zakim, dbaron, Hixie, st, hober, kingryan, h3h, DanC, dino, cwahlers, karl, marcos__, anne, krijnh, Dashiva, jmb, citoyen, gsnedders, Lachy,
# [02:08] <Zakim> ... Yudai, Dave, gavin, Ashe, marcos_, Mallory, hsivonen, jgraham, gavin_, RRSAgent
# [02:08] <Hixie> Zakim, agenda?
# [02:08] <Zakim> I see 6 items remaining on the agenda:
# [02:09] <Zakim> 1. introduction to W3C teleconference tools, Zakim, RRSAgent (20 to 30 minuntes, timed; optional for those that have been to a W3C telcon before) [from DanC]
# [02:09] <Zakim> 2. Convene, take roll, review agenda [from DanC]
# [02:09] <Zakim> 3. Proposed Design Principles [from DanC]
# [02:09] <Zakim> 4. HTML5 review [from DanC]
# [02:09] <Zakim> 5. HTML WG hosting offers: XTech/Paris/May? SFO/June? [from DanC]
# [02:09] <Zakim> 6. regular teleconference slot? (only if I get around to preparing a survey before the call) [from DanC]
# [02:09] <Dashiva> Well, the numbers are right, that's good. I think a lot of people won't recognize that "summer, southern hemisphere" means october through march, though.
# [02:09] <Dashiva> On the other hand, I realize enforcing our northern-hemisphere summer culture on you is unfair :)
# [02:09] <Lachy_> it they don't realise that when it's summer down here, it's winter up there, that's their problem
# [02:10] <Ashe> agreed
# [02:10] <dbaron> people should just use Olson database timezone descriptors
# [02:11] <Lachy_> what are they?
# [02:11] <dbaron> UTC+ doesn't give enough information
# [02:11] <dbaron> America/Los_Angeles, Australia/Sydney, etc.
# [02:11] * Quits: hober (ted@66.162.32.234) (Quit: ERC Version 5.1.3 (IRC client for Emacs))
# [02:11] <Hixie> people should just use UTC
# [02:11] <Hixie> no time zones at all
# [02:11] <dbaron> http://en.wikipedia.org/wiki/Zoneinfo
# [02:11] <Hixie> :-)
# [02:11] <Lachy_> Hixie, agree, but that's not going to happen
# [02:11] <Dashiva> Well, thanks to DST we have two different UTCs per year
# [02:12] <dbaron> two different UTC offsets
# [02:12] <Lachy_> Dashiva: UTC doesn't have DST
# [02:12] <Hixie> Lachy_: well, my point is more that telling you what time zone i'm in doesn't tell you when i'm available for telecons
# [02:12] <Dashiva> Oh, you mean to abolish local time completely?
# [02:12] <Hixie> Dashiva: yeah
# [02:13] <h3h> then you have to make an assumption of availability, no?
# [02:13] <Dashiva> We tried that in the beginning, but DanC vetoed because he would keep entering Bostom time instead.
# [02:13] <Lachy_> it gives a rough approximation under the assumption that people are awake when the sun is up and asleep when it's not
# [02:13] <h3h> or remove the grouping and go back to individual time windows
# [02:14] <Hixie> Dashiva: no i mean in reality. abolish time zones completely. :-)
# [02:14] <h3h> individual time windows mashed up with a google map that highlights all currently available people would be nice
# [02:14] <Dashiva> Didn't Swatch try that back in the 90s? I recall some proposal to switch to a global day with 1000 'ticks'
# [02:14] <h3h> or all available people in an arbitrary time slot
# [02:14] <Lachy_> metric time!
# [02:15] <Hixie> UTC would be fine :-P
# [02:15] <Hixie> but i'm available about 2pm to 6pm, 8pm to 2am, my time zone
# [02:16] <Hixie> so i don't know what saying UTC-8 tells you
# [02:16] <h3h> sounds like a fairly complicated web app
# [02:16] <Dashiva> Saying UTC-8 and also "Young person" might map pretty well to those hours
# [02:17] <Hixie> heh
# [02:17] <Lachy_> I'm available from around 19:00 to 01:00 for telcons
# [02:17] <Lachy_> my time, subtract 10:00 for UTC
# [02:18] <dbaron> you're expecting providing a 6 hour window to match up with everybody else's 6 hour windows? :-P
# [02:19] <dbaron> In reality, you should feel luck to be able to exclude as much as 6 horus.
# [02:19] <dbaron> hours
# [02:19] <h3h> probably just a "best fit"
# [02:19] <Lachy_> No, I don't expect it to match up with everyones
# [02:21] * Joins: DougJ (doug_b_jon@74.76.23.86)
# [02:23] <Hixie> personally i don't see how telecons can possibly work, especially for this group, but i look forward to the meeting to find out
# [02:24] <h3h> I only see it being successful with IRC as the medium
# [02:24] <Dashiva> (( What happened here? http://esw.w3.org/topic/PeopleLocation?action=diff&rev2=63&rev1=62
# [02:25] <Hixie> weird
# [02:25] <Hixie> i'm guessing it's because i used the gui mode then switched to the text mode, made my edit, and submitted
# [02:25] <Hixie> (gui mode didn't work for me)
# [02:25] <Dashiva> Oh wait, you added empty lines separating each section
# [02:25] <Dashiva> Seems the diff view doesn't handle that well
# [02:26] <Hixie> i didn't try to make any change but add my name
# [02:26] <Hixie> so the other changes must be the gui mode
# [02:28] <h3h> yes, the evils of WYSIWYG
# [02:33] <karl> interesting I see Timezones more as a geographical information which could help people to meet in real. :) and then after there is the normal social desire of doing it or not :) but that's up to the individuals
# [02:36] * Quits: kingryan (kingryan@66.92.180.242) (Quit: kingryan)
# [02:38] <Lachy_> I'm a little surpised there are fewer people from Sydney in the group, unless there are others that just havne't listed themselves
# [02:40] <Dashiva> We're still at less than 20% of the members listed
# [02:44] * Joins: olivier (ot@128.30.52.30)
# [02:46] <Lachy_> hmm. There's still a few people who told me they were going to jon the group, but aren't yet listed
# [02:47] <Hixie> i'm amazed that the whatwg is still growing
# [02:47] <Hixie> we're up to 718
# [02:48] <Hixie> and that with the patent nonsense, which, if anything, would drive people away
# [02:48] <Hixie> s/nonsense/discussion/
# [02:49] <Hixie> (228 in public-html, much higher than i expected, makes me very happy that so many people agree that html is important to do in w3c!)
# [02:49] * Joins: Grauw (ask@202.71.92.74)
# [02:51] * Quits: st (st@62.234.155.214) (Quit: st)
# [02:52] <karl> Hixie: for whatwg, when I explained to some people, to encourage them to *join*, the restart of the work of HTML WG at w3c and the history with the WHATWG, many times I had the answer: "what is the WHATWG?" So I encourage them to subscribe the list too.
# [02:55] <Lachy_> I'm surprised there are still people that haven't heard of the WHATWG
# [02:56] <karl> Lachy: most of them. Like many people don't know what the w3c is.
# [02:57] <karl> We have tendency to live in our own caverns
# [02:57] <karl> and forget the real users
# [02:57] <Lachy_> no, I mean even amongst web developers. I don't expect the average joe to know anything about us
# [02:58] * Quits: h3h (bfults@66.162.32.234) (Quit: |)
# [02:58] <karl> yes my point
# [02:58] <karl> web developers
# [02:59] <Lachy_> there must be many that just don't read blogs, since the WHATWG has been discussed on many, including several major ones
# [02:59] <Grauw> Asbjørn, I think the things you mention about the ATOM group$Bc`QT(B process are really good ways to bring more structure in the discussion.
# [03:00] <olivier> Lachy: there's more to the web than english-speaking blogs
# [03:00] <olivier> :)
# [03:00] <Lachy_> what? really?
# [03:00] <Grauw> I tried to keep up with the discussion, in doing so generated even more (I suppose I posted too much), and now I have left the list alone for a few days suddenly there$Bc`QT(B 278 new messages - argh :)
# [03:01] <Lachy_> ;-)
# [03:01] <karl> Lachy: you should know that, you do not speak english, but this strange aussie thing :p
# [03:01] <Lachy_> yeah, fair dinkum!
# [03:02] <Grauw> that$Bc`QT(B also why I suggested to cut up the WHATWG specs into separate items and integrate them into the W3C spec on an individual basis
# [03:03] * Hixie wonders what encoding Grauw is using
# [03:03] * Lachy_ too
# [03:03] <Lachy_> everyone should be using UTF-8
# [03:03] <DougJ> I heard of HTML WG from Surfin' Safari. have been following email list and just finished reading WHATWG Web Applications 1.0 Working Draft. Am 'recreational' web author, but deepely believe in satndards. Am absorbing info before really jumping in with opinions, suggerstions.
# [03:04] <Hixie> Lachy_: i don't recognise it, it seemed like UTF-7 but i don't think it's that either. some variant of punycode maybe?
# [03:04] <Grauw> hmm, it$Bc`QT(B set to UTF-8: display and encode
# [03:04] <Hixie> definitely not UTF-8 :-)
# [03:04] <Grauw> arf
# [03:05] <Hixie> your last line came out as it$Bc'QT(B for me (where ' is the backtick, which i've rewritten to avoid reencoding problems)
# [03:05] <Hixie> as in, "hmm, it$Bc'QT(B set to UTF-8: display and encode"
# [03:05] <Lachy_> your last message looks like this for me: it[\0x1b]$Bc`QT[\0x1b](B set to ...
# [03:05] <Grauw> my...
# [03:07] <Grauw> those look like escape-codes of some sort
# [03:08] * mjs is confused at the same person objecting to both VisibleMetadata and MostlySemanticMarkup principles
# [03:09] <mjs> so what, we should have invisible but non-semantic metadata?
# [03:11] * Lachy_ wonders how meta data can possibly be non-semantic
# [03:11] <Hixie> style="color: red" is stylistic metadata, maybe? dunno :-)
# [03:12] <Lachy_> I wouldn't really call that meta data
# [03:12] <Hixie> i don't really know what the difference between data and metadata is in the <body>
# [03:12] <Grauw> I'm missing an item about new things being done based on some reasonably-well-thought-out architectural point of view :)
# [03:12] <Hixie> i guess if you're giving data annotating other data, as opposed to content
# [03:12] <Hixie> so rel= is metadata, but href= is not
# [03:17] * Quits: Dave (dsr@128.30.52.30) (Ping timeout)
# [03:18] <Grauw> e.g. the question whether you separate all embedded types into separate elements according to their characteristics (<video>, <audio>, <img>), or do you unify them into one (<object>)
# [03:19] <Grauw> I think this discussion should come before the technical details of a possible <video> tag
# [03:19] <mjs> or separate the most common embedded types into separate elements, and still leave <object> as a catchall for remaining cases
# [03:19] <Grauw> just as an example, don't want to get in the whole video-vs-object discussion now :)
# [03:19] <mjs> which is the current approach
# [03:20] <Grauw> well, that's what I mean
# [03:20] <Grauw> why is that the 'current approach'?
# [03:20] <mjs> I just said
# [03:20] <Grauw> was there any discussion about that, or was it just taken for granted
# [03:20] <mjs> or do you mean in general, as opposed to on the specific question you raised?
# [03:21] <Grauw> at what point was the decision taken to go for separate elements (+object fallback) instead of trying to use object for everything (like I think html4 and xhtml2 encourage)
# [03:21] <mjs> on the whatwg list, it was assumed by many contributors, and explained explicitly when the point was raised
# [03:22] <Grauw> that's what I mean with getting the architectural 'rules' set first
# [03:23] <Grauw> I don't read the WhatWG list anymore for quite some time, because the volume was too high for me to keep up :)
# [03:24] <Lachy_> the problem is that a) <object> doesn't really work too well in the real world and there's only so much that can be done to fix it. b) overloading <object> with media specific APIs depending upon what is loaded doesn't make much sense and is a pain to implement
# [03:25] <Grauw> well I said a few things on that topic on the list a few days ago...
# [03:25] <Grauw> but that's not what I'm trying to say right now
# [03:26] <Lachy_> btw, Hixie, are there any plans to introduce <applet> into HTML5? Last time I tried to use <object> for that, it wasn't at all successful
# [03:26] <Lachy_> for java applets, that is
# [03:26] <Grauw> I'm sure to implement <video> is a little easier, because you don't have to deal with backwards compatibility crap, but I don't think <object> is impossible either
# [03:26] <Grauw> which you choose should be based on an architectural discussion
# [03:27] <Grauw> and not on individual cases unless really necessary (because it otherwise wouldn't be possible)
# [03:27] <mjs> Grauw: using <object> would violate "Avoid Needless Complexity", "Degrade Gracefully" (object fallback is not interoperable in current browsers), and "Mostly Semantic Markup"
# [03:27] <mjs> per my proposed html design principles
# [03:28] <Grauw> that's a point of view
# [03:28] <mjs> I think it would also make things worse for users, implementors and content authors
# [03:28] <mjs> while possibly making the spec simpler
# [03:28] * Quits: dbaron (dbaron@207.47.10.130) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [03:28] <mjs> thus violating "Priority of Constituencies"
# [03:28] <Grauw> but it seems you are missing my point, I am just saying that the architectural discussion has not taken place
# [03:29] <Grauw> or at least, it seems to me (I did not follow everything said on the subject on the WhatWG list, although I did read a few messages, amongst others Anne's initial one)
# [03:30] <mjs> that's because we want to "Solve Real Problems", we don't care about coming up with a perfect abstract architecture
# [03:30] <Grauw> well
# [03:30] <Grauw> that's what I was afraid of
# [03:30] <Grauw> I'm not saying it has to be perfect
# [03:30] * mjs thinks he did a good job of capturing the WHATWG's implicit design principles, based on this conversation
# [03:31] <Grauw> but I was just writing a mail that "Solve Real Problems" could be used as an excuse to ignore architectural considerations
# [03:31] <mjs> can and should
# [03:31] <mjs> if the architectural considerations don't relate to real problems
# [03:31] <Grauw> that is an assumption
# [03:32] <Grauw> generally the idea is that architectural considerations do solve real problems
# [03:32] <Lachy_> Grauw: I don't understand, we're discussing the architecture now, and all of this stuff has been discussed before
# [03:32] <mjs> well, Solve Real Problems just says you need to be clear on what problem the architectural consideration is solving
# [03:33] <mjs> it doesn't say you can't consider the architecture, just that it is a means to an end, not a thing in itself
# [03:33] <mjs> for example, if some architectural issue makes authoring easier, then it solves a real problem
# [03:33] <Grauw> well you just used it in a different meaning then, mjs :)
# [03:33] <mjs> check what's written down here: http://esw.w3.org/topic/HTML/ProposedDesignPrinciples
# [03:33] <Grauw> Lachy_: I suppose it ties into Asbjørn's mail about getting more structure in the discussion
# [03:33] <Grauw> I've read it, mjs
# [03:34] <DougJ> Since a lot of what the HTML WG is looking at has been discussed by the WHATWG, those familiar with the WHATWG should try to create a Table of Contents of links pointing to their Design Principles, Reasons for Choosing the Path they did, etc. This may prvent the rehashing of issues that has already begun. Or t least provide a reasonable starting point.
# [03:34] <Grauw> DougJ, if that could be provided it would be great
# [03:35] <DougJ> Yeah, but I'm not the one. I haven't been involved with the WHATWG.
# [03:35] <Grauw> Lachy_: I'd like to discuss individual topics, and in those discussions start with the architecture and use cases, and only after those have been discussed come up with a solution
# [03:35] <Lachy_> DougJ: most of the discussion is in the archives of whatwg, but the problem is getting someone who has the time to both keep upwith the list and also create an index of issues/resolutions, etc
# [03:36] <Grauw> in the case of the <video> element, it seems to have gone the other way around, and trying to discuss architecture and use cases is kind of hard when there is a lot of discussion about a proposal -an implementation even- going on
# [03:36] <DougJ> Understood
# [03:36] <Lachy_> Grauw: that sounds exactly like what I wrote in my e-mails to Mike on the list
# [03:37] <Grauw> and if I read comments like "I delete most of it without reading it, frankly." - it makes me feel like emails I write are lost in the masses
# [03:37] <Lachy_> there are plenty of use cases for video: YouTube, Google Video, and any other sites that use Flash or rely on plugins for playing video
# [03:38] <Grauw> all those sites work with the mechanics provided today
# [03:38] <Lachy_> yes, and the problem is that they require proprietary technologies like flash to work
# [03:38] <Grauw> if that is the problem, then there is no reason anything has to be added to the spec
# [03:38] <Grauw> let alone a new element
# [03:39] <Lachy_> the aim is to make video a first class citizen on the web like images
# [03:39] <Grauw> browsers can implement Theora natively and let it work off the <object> element
# [03:39] <Grauw> that's a different objective, and one I do not see a good use case for
# [03:39] <mjs> the fact that Flash provides a solution to the web video problem doesn't mean that HTML shouldn't
# [03:40] <Grauw> HTML *does* provide a solution to web video, <object>
# [03:40] <Grauw> anyway, I don't want to engage in this discussion here on IRC :)
# [03:40] <Lachy_> sure, they could potentially do that, but there's also the problem of providing an API for scripts
# [03:40] <mjs> and clearly the web has found it inadequate as a solution
# [03:40] <Grauw> which I have provided a solution for
# [03:40] <mjs> gotta go
# [03:40] <Lachy_> <object> isn't an ideal solution
# [03:40] <mjs> so, basically, people disagree with you on the basis of genuine problems raised by using <object>
# [03:40] <mjs> you can make counter-arguments
# [03:40] <Grauw> I'd like that to be discussed
# [03:41] <mjs> trying to raise things to the level of "architecture" divorced from the concrete issue is not going to fly
# [03:41] <Grauw> mjs, I don't see why, and that is an opinion
# [03:41] * Quits: mjs (mjs@17.255.97.200) (Quit: mjs)
# [03:41] <Dashiva> What are the reasons for reusing object, though?
# [03:42] <Dashiva> All I recall seeing reduces to "We only need <div>, <span> and <object>, the other elements are bloat"
# [03:42] <Grauw> what are the reasons for not reusing it, I'd ask rather, because reusing object works to some extent with current browsers, whereas <video> does not
# [03:42] * Joins: mjs (mjs@17.255.97.200)
# [03:42] <Grauw> but anyway, I really don't want to discuss this here :)
# [03:42] <Lachy_> why is it a good thing to unify the embedding of all types into a single element, especially when that has proven ineffective in the real world?
# [03:42] <Dashiva> Because video as proposed is significantly different from plugin-based video
# [03:43] <mjs> if you respond to every statement about how the group decides things with "that is an opinion", it is hard to discuss anything productively
# [03:43] * Quits: mjs (mjs@17.255.97.200) (Quit: mjs)
# [03:43] <Lachy_> Technically, UAs could still support some codecs through plugins, that should be completely transparent to authors and users
# [03:43] <Grauw> IRC is 1. too volatile a medium to properly archive and later reference any good points made, and 2. I can't both order my thoughts and type fast enough to keep up with the fast pace :)
# [03:45] <anne> are we still debating whether we need <tag role>?
# [03:45] * anne hoped that was over
# [03:45] <Grauw> ?
# [03:45] <Dashiva> Good arguments should be distilled and publicized anyway, so IRC is as good as anywhere
# [03:46] <Grauw> that's true
# [03:46] <Grauw> but I at least find it easier to properly respond to mail
# [03:46] <Dashiva> I do agree a hundred lines of quoting (like seen previously) is not optimal
# [03:47] <Grauw> when I have the time to re-read what I say, and check with resources if it's correct, etc
# [03:47] <Grauw> and construct a link to another mail I wrote about the subject so that I don't have to reiterate myself
# [03:47] <Grauw> stuff like that
# [03:48] <Dashiva> Put stuff you want to reference on the wiki
# [03:49] <Dashiva> That way it can be updated to remain the latest and most complete reference on the subject, rather than having to sift through a serious of mails which may or may not obsolete previous ones
# [03:49] <Lachy_> Grauw: be sure to search the archives of whatwg for discussion of video vs. object. There's some stuff recently and also around October last year (I think)
# [03:49] <Grauw> Lachy: you know how long that would take me?
# [03:50] <Grauw> you have read it, why don't you provide me with pointers to the good ones :)
# [03:50] <Lachy_> well, there's no point rehashing old arguments that we've all seen before
# [03:50] <Lachy_> I'd have to find them
# [03:50] <Grauw> so even you, who know what you're looking for, needs time to find them :)
# [03:50] <Lachy_> and considering I'm not the one who has an issue with <video>, it's not up to me to research for you
# [03:51] <Grauw> note that if those arguments had been made on IRC, it would have been pretty much impossible to find them back
# [03:51] <Grauw> I'm not asking you to, of course :)
# [03:52] <Dashiva> Well, right tools for the job. IRC is for making progress, not reference
# [03:53] <Grauw> and upsetting people (like mjs just now >.<)
# [03:54] <Dashiva> And also people venting because they're upset by stuff said on mail
# [03:55] <Grauw> anyway, to get back to my original points, I like Asbjørn's mail about bringing structure in the discussion (WG Process (was: Re: wow...)), and I am missing architecture as a consideration in the DesignPrinciples document - the only place where it's mentioned actually argues against considering architecture
# [03:56] * anne wonders what kind of architecture is needed really
# [03:56] * Lachy_ too
# [03:56] <anne> I suppose you could make an argument for "ConsistentLanguageDesign"
# [03:56] <anne> (where possible)
# [03:56] <Grauw> yes, I suppose too
# [03:58] <anne> but the architecture seems mostly in place
# [03:58] <Lachy_> I just don't understand exactly what it is about <object> that makes it such a great architecture
# [04:00] <anne> it's a great element for generic inclusion
# [04:00] <Grauw> well to me, it seems wrong to try to separate out things that are not really fundamentally different
# [04:00] <anne> browsing contexts, SVG, XML, HTML, video, audio, etc.
# [04:01] <Lachy_> those things are all fundamentally different
# [04:01] <anne> it's not great building an API on top of it for a specific type of content
# [04:01] <Grauw> plus that I still don't understand whether <video> is supposed to have native implementations, or whether 3rd-party providers are allowed to plug in to it
# [04:01] <anne> Grauw, that's up to implementations, surely
# [04:01] <Grauw> anne, I wrote a mail about that, that they are not really different in essence
# [04:01] <Lachy_> whether it's native or provided by a plugin is an implementation detail
# [04:02] <Grauw> I suppose that's true
# [04:02] <Grauw> although <object> provides specific means for it
# [04:02] <Grauw> whether or not they're good is a different subject of course (implementations at least certainly don't seem to follow them)
# [04:03] <Grauw> personally, I think an implementation should be able to find a plugin based on media type alone
# [04:03] <anne> what does <object> provide?
# [04:03] <anne> Grauw, I'm not sure what you mean with that sentence "they are not really different in essense"
# [04:04] * anne wonders why Murray posts in the future
# [04:04] <Dashiva> Object doesn't really provide anything, just a bunch of attributes that get (ab)used in incompatible ways
# [04:04] * Quits: DougJ (doug_b_jon@74.76.23.86) (Quit: DougJ)
# [04:04] <Dashiva> anne: I asked the same earlier. :)
# [04:04] * Joins: DougJ (doug_b_jon@74.76.23.86)
# [04:04] <Grauw> dashiva: that's what I just said, isn't it :)
# [04:05] <Grauw> audio and video are just either sound samples or images replayed along a timeline
# [04:05] * Quits: DougJ (doug_b_jon@74.76.23.86) (Quit: DougJ)
# [04:05] <Grauw> video is different from images in that it has a timeline, but all properties that apply to images apply to video
# [04:06] <Grauw> and all properties that apply to a timeline apply to video and audio
# [04:06] * Joins: johnst (johnst@83.89.44.198)
# [04:07] <Grauw> in the end they're all just expressions that are aimed (in different combinations) at our ears, eyes, and fingers
# [04:08] <Grauw> to try to separate certain combinations (e.g. for ears -audio-, for ears+eyes -video-, for ears+eyes+fingers -flash-) seems kind of...
# [04:08] <Grauw> arbitrary
# [04:08] <anne> <video> and <audio> are based on the same interface
# [04:08] <anne> they are different elements because they represent different things
# [04:08] <Grauw> what's so different?
# [04:08] <anne> (and <video> has an intrinsic height and width)
# [04:09] <anne> see the HTML5 spec
# [04:10] <Lachy_> Grauw: you seem to recognise the differences between images, audio and video, but somehow you're discounting those differences as minor and reaching the conclusion that they're fundamentally the same. That seems like a self defeating argument to me
# [04:11] <Grauw> what?
# [04:11] <Grauw> of course there are differences, just like video and video+audio are different
# [04:12] <Grauw> are you providing a <video-audio> element? no
# [04:12] <Grauw> what about animated gifs, you want them in <video>?
# [04:12] <Lachy_> no, but that's essentially what you're asking for with <object>
# [04:12] <Grauw> what about flash without any interactivity, can't that be <video>
# [04:13] <Dashiva> If a UA wants to provide a flash splitter and codecs, sure
# [04:13] <Lachy_> Flash: no
# [04:14] <Grauw> if you were consistent in separating out different types of media (like you seem to want to do with <audio> and <video>) you should put animated gifs in <video> and movie clips with audio in an <video-audio> element
# [04:14] <Lachy_> animated gifs: couldn't really be classified as video in this context, so no
# [04:14] <Grauw> why not?
# [04:14] <Grauw> they're the same
# [04:14] <Grauw> just using a different technology
# [04:14] <Lachy_> they're fundamentally different in the way they work
# [04:15] <Grauw> animated gifs are exactly the same as an .ogg file
# [04:15] <Lachy_> ha!
# [04:15] <Grauw> a flash movie may work a little different, with vector graphics on a timeline instead of bitmap images, but the end-result is the same
# [04:16] <Grauw> if you want to express semantics with <video>, the element should apply to all those
# [04:16] <anne> if UAs support it I don't see why not
# [04:16] * anne isn't sure UAs will support it though
# [04:16] <anne> especially silly things like aGIF
# [04:17] <Grauw> if aGIF is so silly, then why did Mozilla bother implementing APNG :)
# [04:17] <Dashiva> animated gifs don't have the "complex" container/codec setup that makes video tricky
# [04:17] <anne> because APNG isn't silly
# [04:17] <anne> or less, at least
# [04:17] <Grauw> it's the same, except with 256-bit transparency
# [04:18] <anne> but in general that's not what <video> is for
# [04:18] <anne> UAs could even support HTML in <video>
# [04:19] <Grauw> I say, if you want to provide API, you can tack it onto <object>
# [04:19] <anne> but it wouldn't make much sense
# [04:19] <Grauw> if you want to provide embedding support, <object> already does it
# [04:19] <Lachy_> <object> is so broken, it's difficult to fix it well enough for that
# [04:19] <Grauw> if you want to provide semantics that are more specific than <object>'s, then <video> doesn't really do a good job either
# [04:20] <Grauw> ok, so create an <include> element :) (wasn't that what it was called in the initial proposal way back? :))
# [04:20] <Lachy_> and, as I said earlier, providing media specific APIs depending on what's loaded does not make any sense
# [04:20] <Lachy_> either from an authors point of view nor implementors
# [04:20] <Grauw> Lachy_: I wrote a message to the HTML WG list explaining that the API is not necessarily media specific
# [04:20] <anne> the API has been abstracted to deal with that
# [04:20] <Grauw> arf, let me rephrase that
# [04:21] <anne> see the proposal...
# [04:21] <anne> anyway, it's 4:20AM here
# [04:21] <Grauw> with proposal you mean the spec WD?
# [04:21] <Grauw> 11:20 am :)
# [04:21] <anne> oh, AOL joined the WG
# [04:21] <Grauw> I haven't had time to read it yet
# [04:21] <Grauw> that's great
# [04:22] <Grauw> plus if it's only a proposal, why is it in the spec already :)
# [04:22] <anne> the spec is a proposal
# [04:22] <Grauw> Hixie's proposal :)
# [04:22] <anne> well, from the WHATWG
# [04:23] <anne> but it doesn't have WHATWG consensus or anything
# [04:25] <Grauw> Wrt encoding, if I join a test channel (using mIRC) and type non-ASCII characters, it shows up correctly in another instance of me there using X-Chat2
# [04:25] <Grauw> set to UTF-8
# [04:25] <Grauw> so I'm kind of puzzled
# [04:26] <anne> i'm not sure what they argued about either, your messages showed up fine here
# [04:26] <Grauw> maybe X-Chat2 also supports this ANSI-encoding scheme
# [04:26] <Grauw> (which it looked like)
# [04:28] <Grauw> anyway
# [04:28] <Grauw> Anne, goodnight, get some good sleep :)
# [04:28] * Joins: zcorpan (zcorpan@84.216.42.243)
# [04:30] <anne> yeah, I should
# [04:30] <Grauw> ^_^
# [04:32] * Joins: h3h (bfults@70.95.237.98)
# [04:35] * Quits: anne (annevk@81.68.67.12) (Ping timeout)
# [04:40] <Grauw> also, it shows up correctly in the logs
# [04:40] <Grauw> I don't think my configuration is wrong
# [04:44] * Quits: zcorpan (zcorpan@84.216.42.243) (Ping timeout)
# [05:15] * Joins: zcorpan (zcorpan@84.216.42.243)
# [05:36] <Grauw> WRT my 278-new-messages concern, I am happy to see that many of those new messages actually contain nothing else than '+1' :) I like that convention
# [05:39] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [05:45] * Joins: gavin (gavin@74.103.208.221)
# [05:55] * Quits: zcorpan (zcorpan@84.216.42.243) (Ping timeout)
# [06:30] * Joins: heycam (cam@130.194.72.84)
# [06:53] <karl> http://www.w3.org/2000/09/dbwg/details?group=40318&public=1
# [06:53] <karl> 230 participants and AOL is in.
# [07:02] <Grauw> I just finished ploughing through the 278 new messages.
# [07:02] <Grauw> Only took me 5 hours >.<
# [07:02] <karl> :)
# [07:02] <Grauw> btw, I see you're in Japan as well :)
# [07:03] <karl> Grauw: yes
# [07:03] <karl> shimokitazawa, right now.
# [07:03] <Grauw> maybe we should have that f2f meeting in Japan after all ;p
# [07:03] <Grauw> I'm in Kyoto, don't know too much about Tokyo really :)
# [07:04] <karl> hehe
# [07:04] <Grauw> I was there for the first time last month, for four days, after coming down from Hokkaido (visiting for the yuki matsuri).
# [07:05] <karl> I think there will be a another barcamp in Tokyo.
# [07:06] <Grauw> oh really? that's nice
# [07:06] <karl> http://barcamp.org/BarCampTokyo
# [07:07] <Grauw> I found it
# [07:07] <karl> maybe you should create http://barcamp.org/BarCampKyoto
# [07:07] <Grauw> ;p
# [07:08] * Joins: tylerr (tylerr@24.16.148.66)
# [07:08] * Quits: tylerr (tylerr@24.16.148.66) (Quit: Leaving)
# [07:08] * Joins: tylerr (tylerr@24.16.148.66)
# [07:08] <tylerr> Hello all.
# [07:47] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [07:52] * Joins: gavin (gavin@74.103.208.221)
# [07:56] * Quits: olivier (ot@128.30.52.30) (Client exited)
# [07:57] * Joins: mjs (mjs@64.81.48.145)
# [08:01] * karl is reading http://www.w3.org/html/wg/il16
# [08:09] <tylerr> Pretty interesting stuff eh karl?
# [08:18] <mjs> what is with people putting "SPAM-LOW" in the subject line
# [08:18] <mjs> did I miss the memo on this?
# [08:18] <tylerr> I wish I knew.
# [08:20] <mjs> it seems to be used mainly by someone whose level of SPAM is hardly LOW
# [08:21] <tylerr> Maybe they consider the majority of the list's mail at important spam?
# [08:23] <mjs> I have no idea
# [08:30] <Grauw> mjs, maybe you should separate out the things that you think are ‘hard rules’ and the things that are more like guidelines
# [08:30] <Grauw> if such a distinction is possible
# [08:32] <mjs> Grauw: I don't think any of the design principles are hard rules
# [08:32] <mjs> at least to me
# [08:32] <mjs> I am a pragmatic person, and recognize that different design goals may sometimes be in conflict
# [08:32] <Grauw> I suppose you're right
# [08:33] <mjs> This is why I worded most of the principles with words like "prefer" or "usually" or "often"
# [08:33] <Grauw> some seem stronger than others, but even they have different interpretations I guess
# [08:33] <Grauw> like don't break the web"
# [08:33] <Grauw> if you look at how much dbaron had to write on the subject :)
# [08:33] <mjs> even Don't Break The Web, as dbaron originally wrote it, is a balance between value of a change vs. amount and type of content broken by it
# [08:34] <mjs> since in theory any change might break *some*thing
# [08:34] <Grauw> yeah
# [08:35] <mjs> I think I fundamentally disagree with you that the right approach is to decide on architecture first, then proceed to solve problems
# [08:36] <mjs> I think instead the problems and the ways you would solve them should inform the architecture
# [08:36] <Grauw> I'm not necessarily saying that they need to be happening in that order, and of course architecture should be based on use cases
# [08:36] <Grauw> but it seems generally a good idea to look at architecture first, because that defines the basis of the implementation
# [08:37] <mjs> but yes, I do think architecture has no intrinsic value, except as a way to address concrete issues
# [08:37] <mjs> it is a means to an end, not an end in itself
# [08:37] <mjs> so I would oppose a principle like "Good Architecture" because to me it means nothing
# [08:37] <Grauw> of course, but it's a good means, meant to bring structure in the definition process :)
# [08:38] <tylerr> Has there been any forward progress on deciding the approach? Are we looking at architecting around XHTML2/WebApps1.0 or taking from both and building up from there?
# [08:38] <Grauw> I don't think so...
# [08:40] <mjs> I have an opinion on the right approach, but I don't want to debate it yet, because it seems polite to give our co-chair time to work his corporate bureaucracy
# [08:41] <Grauw> do you suppose you can give an irc-only sneak peek?
# [08:42] <mjs> I think we should adopt Web Apps 1.0 / HTML5 as the starting point
# [08:42] <mjs> and begin with a feature review
# [08:42] <mjs> and have Ian Hickson as editor
# [08:43] <mjs> I don't think detail review is needed to adopt the spec initially
# [08:43] <Grauw> with feature review you mean say, make a list of distinct features of the spec and address one every week?
# [08:44] <Grauw> well that sounds sensible
# [08:44] <Grauw> :)
# [08:44] <mjs> no, I mean determine added and removed features relative to HTML4.01, and see if there are any the group as a whole objects to, or where the group has issues to the approach
# [08:45] <Grauw> well yes, that’s kind of what I meant (I said ‘one every week’ just because it seems that there may be a lot of them)
# [08:45] <mjs> then people can review any part they want as they wish closely, though some people may volunteer to lead closer review of some areas
# [08:46] <Grauw> aha
# [08:46] <mjs> but there will also be a natural focus of discussion on new areas of development
# [08:46] <mjs> the way currently in whatwg <audio>/<video> is a big focus
# [08:48] <Grauw> well given the volume of the list (mainly this weekend, but you see the same thing on the WHATWG list), maybe there would be merit to dose it a little... I dunno.
# [08:50] <mjs> I don't know if it is either possible or desirable to stop people from commenting, but we could encourage people to stick to focus topics
# [08:50] <Grauw> that sounds like a good idea
# [08:51] <Grauw> declare august to be "the month of text" :)
# [08:52] <mjs> right now I an encouraging design principles as a focus topic, because I think it is good to have a shared understanding of what guides specific decisions, and also because I think discussing specific technical issues is premature before we decide our baseline, and deciding our baseline is hard to do w/o the co-chair who may have a strong opinion on the matter
# [08:52] <mjs> (as might his organization)
# [08:54] <Grauw> I think by the way those design principles are not too different from what I mean by architecture, really :)
# [08:54] <Grauw> just a little more fleshed out
# [08:54] <Grauw> and maybe covering more specific topics
# [08:55] <Grauw> but I see you already have an outline for the fleshing-out in the detailed pages
# [08:55] * Quits: johnst (johnst@83.89.44.198) (Quit: Leaving)
# [08:56] <mjs> yes
# [08:56] <mjs> and I'm trying to avoid more specific topics
# [08:56] <mjs> though others have proposed things like "no versioning"
# [08:56] <mjs> I do want to clarify or correct the specific principles that drew comments
# [08:57] <Grauw> well with specific topics I rather mean something like 'where to you draw the line for adding an element'
# [08:57] <Grauw> which could describe a few guidelines for when an element should be included or not, and what alternatives there may be (e.g. XHTML2 offered role as alternative)
# [08:59] <mjs> I think many of the principles inform that decision
# [09:00] <mjs> I also posted a discussion of why primary semantics should be carried by elements, not attributes, but I think that may be too specific to be a design principle on this list
# [09:01] <Grauw> I think it could very well be, but it needs to be discussed first
# [09:02] <Grauw> also clarified what 'primary semantics' mean exactly, etc
# [09:03] <Grauw> re "I think many of the principles inform that decition", I think those principles are more about if you create an element, how to create it
# [09:04] <mjs> not necessarily, they also guide whether to create an element for something or not
# [09:05] <mjs> the various compatibility-related ones all give some weight to any argument against making a new element
# [09:05] <mjs> so it needs to justify itself sufficiently on the basis of the others
# [09:05] <Grauw> that's true
# [09:06] <mjs> Avoid Needless Complexity also gives some level of presumption against any new feature at all, whether it is an element or not
# [09:07] <Grauw> the thing is I suppose that they tell you what you should consider, but not how you should do it
# [09:07] <Grauw> e.g. Support World Languages does not mention that element content is preferred over attribute content for this
# [09:07] <Grauw> also, a general design principle of 'element content for human, attribute content for machine' would be nice to have
# [09:08] <mjs> is that really true though?
# [09:08] <mjs> machines often want to read element contents
# [09:08] <mjs> and attribute contents often affect presentation / behavior
# [09:08] <Grauw> it is not true in HTML (title attribute), but in general I think it is
# [09:09] <mjs> well, these are design principles for HTML
# [09:09] <Grauw> well that's not exactly what I mean
# [09:09] <Grauw> there's nothing wrong with machines reading element contents, or attributes changing human interaction
# [09:09] <Grauw> but e.g. in the DOM attributes are normalised differently for easier machine processing
# [09:10] <Grauw> and elements allow for sub-elements that are important for language, such as direction changes, <sup>, <sub>, ruby, etc
# [09:10] <Grauw> language that needs to be interpreted by humans, not machines
# [09:11] <mjs> I agree that human-readable content should be marked up text inside an element, not an attribute
# [09:11] <Grauw> well, I think you could call that a design principle
# [09:12] <Grauw> one of the more 'specific topics'
# [09:12] * Quits: h3h (bfults@70.95.237.98) (Quit: h3h)
# [09:13] <mjs> yes, probably
# [09:13] <mjs> <img> violates it but of course other principles argue against fixing that
# [09:14] <Grauw> XHTML2 fixed it :), and so does <object>.
# [09:14] <Grauw> (theoretically)
# [09:14] <mjs> yes, but XHTML2 violates many of the design principles
# [09:15] <Grauw> yes, their charter is based on different ideas
# [09:15] <Grauw> does not mean however that they don't have good ideas :)
# [09:15] <mjs> I'm not against mining their good ideas
# [09:15] <Lachy_> XHTML2 violates the don't break the web principle
# [09:15] <Grauw> if browsers (read: IE) would actually hook up their native image rendering to <object>, I think you could start to use it for embedding images with non-attribute alternative text
# [09:16] <mjs> I don't think "src on everything" is a good idea
# [09:16] <mjs> and I don't think "use object for all embedding" is a good idea
# [09:16] <Grauw> I don$Bc`QU(B really have an opinion for src on everything... mostly seems like a gimmick to me.
# [09:17] <Grauw> ah, sorry, I confused href with src :)
# [09:17] <mjs> I can explain to you why I think they are bad in reference to the principles if you want, but it seems kinda obvious to me
# [09:17] <Grauw> I kind of like the thought of things like <p src="diagram.png">Diagram showing that this and that.</p>
# [09:18] <Grauw> yes, it would never work on the current web
# [09:18] <mjs> I don't think it's very good semantically even
# [09:18] <mjs> an image is not a paragraph
# [09:18] <Grauw> ...maybe, but image nowadays also has problems:
# [09:19] <Grauw> You always have to put it in a block-level element; <p><img/></p>
# [09:19] <Grauw> that's basically the same problem, I suppose :)
# [09:19] <mjs> unless it is an inline or floating image
# [09:19] <Grauw> yes
# [09:19] <Grauw> actually
# [09:19] <mjs> and HTML5 has <figure> for purposes of a captioned block-level illustration
# [09:19] <Grauw> lemme change my example above
# [09:20] <Grauw> <h1 src="logo-heading.png">Web inc.</h1>
# [09:20] <Grauw> there you can definitely say that the image is a heading
# [09:22] <Grauw> or <li src="articles.png" href="articles.html">Articles</li>
# [09:22] <mjs> image replacement is a presentational concern
# [09:22] <Grauw> but of course you could state the same with elements, I think it's more like a gimmick to shorten
# [09:23] <mjs> images in markup are only interesting if they are semantic, not just a bitmap way of styling the text
# [09:23] <Grauw> ok the li may be a bad example :)
# [09:24] <Grauw> in case of the logo the logo image would likely include the logo graphic though, and the text inside is only a copy of the textual content of the logo
# [09:25] <Grauw> anyway, img can be abused just like and src attribute of course, so there's no different here
# [09:25] <Grauw> *an
# [09:26] <Grauw> oh, <figure> I like a lot about web apps 1.0
# [09:26] <Grauw> although of course it does not only apply to still images, which the name suggests (but oh well)
# [09:26] <mjs> imahe header is more borderline
# [09:26] <mjs> er
# [09:26] <mjs> image header
# [09:27] <mjs> I don't see much of a problem with putting the <img> in the header, and it would be better still to do the text part through styling so you can select and copy the text, do finds in it, etc
# [09:27] <Grauw> I don't think it's borderline, it's a legitimate use.
# [09:28] * Quits: Lachy_ (chatzilla@220.245.91.147) (Quit: Chatzilla 0.9.77 [Firefox 2.0.0.3/2007030919])
# [09:28] <Grauw> usually with alt text if you copy the image then you copy the alt text...
# [09:28] <mjs> I mean it's borderline whether that is just presentational styling or a semantic use of an image as a header
# [09:28] <mjs> obviously image + text is also something you want to support
# [09:28] <Grauw> yes
# [09:28] <mjs> and <h1><img></h1> seems no worse than <h1><img>some text</h1>
# [09:28] <Grauw> in that case the latter example would seem better
# [09:29] <Grauw> as I said, I see the XHTML2 src attribute as a shortening of putting an image tag in the element, not as really addressing a specific problem
# [09:30] <Grauw> just a bit nicer way of writing
# [09:30] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
# [09:31] <Grauw> of course not one that will work in current browsers, unless you use XBL
# [09:31] <mjs> well, whether it's nicer is somewhat debatable
# [09:31] <Grauw> I agree
# [09:39] * Quits: tylerr (tylerr@24.16.148.66) (Quit: This computer has gone to sleep)
# [09:50] * karl is reading http://www.w3.org/MarkUp/html-spec/html-essay.html
# [09:53] <karl> which led me to http://www.w3.org/History.html
# [09:53] <karl> damn hypertext!
# [09:55] <karl> The hypertext markup language is an SGML format.
# [09:55] <karl> --Tim Berners-Lee, in "About HTML"
# [09:55] <karl> The result of that design decision is something of a collision between the World Wide Web development community and the SGML community -- between the quick-and-dirty software community and the formal ISO standards community. It also creates a collision between the interactive, online hypermedia technology and the bulk, batch print publications technology.
# [09:55] <karl> in http://www.w3.org/MarkUp/SGML/sgml-lex/sgml-lex
# [10:01] <karl> http://www.w3.org/MarkUp/WD-doctypes
# [10:01] <karl> Introduction
# [10:01] <karl> The goal of any HTML specification should be to promote that confidence in the fidelity of communications using HTML. This means:
# [10:01] <karl> 1. making it clear to authors what idioms are available
# [10:01] <karl> 2. making it clear to implementors how to interpret the
# [10:01] <karl> 3. keeping HTML simple enough that it can be implemented
# [10:01] <karl> 4. making HTML expressive enough that it can represent a useful majority of the contemporary communications idioms in this community
# [10:01] <karl> 5. making some allowance for expressing idioms not captured by the specification
# [10:01] <karl> 6. addressing relavent interoperability issues with other applications and technologies
# [10:02] <mjs> good to know some of those principles have passed on in the oral tradition
# [10:03] <Grauw> so negative!
# [10:04] <mjs> who, me?
# [10:04] * mjs thought that was a positive comment
# [10:04] <mjs> in that we came up with some of the same concepts w/o (at least in my case) ever having seen that document
# [10:06] <Grauw> I'm sure the HTML4 spec leaves much to be desired, but I have been referencing it for several years in creating web pages and have never found significant problems with it
# [10:10] <mjs> that's great that it meets your needs
# [10:10] <mjs> but for others, it leaves something to be desired
# [10:10] <mjs> it calls for some things that are incompatible with actual practice in various ways
# [10:11] <mjs> it defines many things too vaguely for interoperable implementation
# [10:11] <Grauw> but it also does a lot right
# [10:11] <mjs> and it does not reflect the advances in the state of the web since it was first issued
# [10:11] <Grauw> bitching about the W3C is a hot thing to do nowadays
# [10:12] <mjs> I don't think anyone here is bitching
# [10:12] <mjs> I think many people agree a new version of HTML is overdue, and a lot of them have volunteered to help with it, under W3C auspices
# [10:12] <Grauw> well it was a sarcastic comment, and I say "so negative" because I think it's too negative
# [10:13] <mjs> it was not meant to be sarcastic
# [10:13] * Joins: ROBOd (robod@86.34.246.154)
# [10:13] <Grauw> I don't mean to say HTML4 is perfect or that HTML5 is not needed :)
# [10:13] <Grauw> well it sounded like one
# [10:13] <Grauw> :)
# [10:13] <mjs> I can't see how
# [10:14] <mjs> it's good to see that we share some of the same principles today, even if we word them differently or expound on them in more detail
# [10:14] <Grauw> how I read it is, "good to know some of those principles have passed on in the oral tradition" - in other words, you don't think highly of how they achieved it in their specifications
# [10:15] <mjs> no, I just mean that I don't think many people in the web standards community of today haev read that document
# [10:16] <Grauw> then I misinterpreted, sorry :)
# [10:16] <mjs> I do think HTML4 does fall short in the area of being clear to implementors, but that is a separate point
# [10:29] <karl> yes I understood mjs saying that the Web became something more part of our culture.
# [10:29] <karl> Design principles
# [10:29] <karl> there will be changes,
# [10:29] <karl> evolutions, and different opinions for sure, but in the end there has been a lot of progress in the understanding.
# [10:38] * Joins: heycam (cam@203.214.81.60)
# [10:52] * Joins: Dave (dsr@128.30.52.30)
# [11:06] * Looking up karl user info...
# [11:30] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [11:59] <Lachy> oh my gosh, does anyone understand the "Multipart response support" post?
# [11:59] <krijnh> I don't
# [11:59] <Lachy> I never thought I'd see a request for adding DRM to HTML
# [12:00] <krijnh> En good morning
# [12:00] <krijnh> *And
# [12:19] <hsivonen> Lachy: I decided not to reply in the hope that it gets ignored without the discussion exploding and then going down armchair lawyering and politics rathole
# [12:20] <hsivonen> (alhough I do have a very specific opinion about this)
# [12:20] <Lachy> I've written my response, but I'm not sure if I should send it
# [12:21] <Lachy> the first part of my response is a rant about no DRM, the I question the motives behind it and then say how multipart/* MIMEs and CID URIs are already used for that purpose in e-mails
# [12:23] <Lachy> hmm. your probably right, it might turn into a flamewar about DRM or other nonsense. It's probably not worth sending.
# [12:23] <hsivonen> (my opinion is that to avoid implementors and users invoking anti-circumvention legislation, the WG should not define any features whose most obvious use case or stated rationale would make the feature plausibly constitute and effective technical protection measure under the DMCA or the EUCD)
# [12:23] <hsivonen> s/and effective/an effective/
# [12:24] <Lachy> right. That's a nice technical way of putting it. I was just going to go with "Under no circumstances must there be any attempt to introduce any digital *restrictions* management (DRM) into anything related to HTML"
# [12:26] <hsivonen> Lachy: your opinion is principled. my formulation is based on an argument about avoiding legal risk. :-)
# [12:27] <Lachy> :-)
# [12:29] <ROBOd> having anything DRM-like in HTML ... would simply be against the purpose of a completely open web standard
# [12:31] <ROBOd> such features would turn HTML into a Flash-like/PDF-like/WhateverProprietaryFormat-like "product" which would be very attractive to companies/corporations interested of copyright protection, of ways to restrict their content usage, et cetera
# [12:33] <ROBOd> such requests shall be ignored
# [12:35] * Quits: marcos__ (chatzilla@131.181.148.226) (Quit: ...and I'm gone.)
# [12:39] * Joins: marcos__ (chatzilla@131.181.148.226)
# [12:46] * Quits: Lachy (Lachlan@210.84.40.143) (Quit: Leaving)
# [12:46] * Joins: Lachy (Lachlan@210.84.40.143)
# [12:59] * Quits: marcos__ (chatzilla@131.181.148.226) (Quit: ...Marcos.sleep();)
# [13:18] * Quits: Lachy (Lachlan@210.84.40.143) (Connection reset by peer)
# [13:19] * Joins: Lachy (Lachlan@210.84.40.143)
# [13:23] * Quits: Lachy (Lachlan@210.84.40.143) (Quit: This computer has gone to sleep)
# [13:39] * Joins: Lachy (Lachlan@210.84.40.143)
# [13:44] * Parts: asbjornu (asbjorn@84.48.116.134)
# [13:55] <Grauw> re: "authors will at least prohibit links directly into those images" I want to say that raising such barriers is against the nature of the web, but I'll just say it here and not mail it :)
# [14:03] * Joins: olivier (ot@128.30.52.30)
# [14:07] <Grauw> Henri, I know the arguments against <h> <l> and <separator> :), think they make sense too, it was just a p.s. of my personal opinion. Imho it's relatively easy to change and still have it work, and the naming would be better, but I don$Bc`QU(B expect it to get in HTML5. Although I would like them as secondary options, but I don$Bc`QU(B think that$Bc`QT(B going to happen.
# [14:08] <Lachy> what are the benefits of introducing such new elements?
# [14:09] <Lachy> to me, it seems like little more than a theoretical benefit based upon the name, rather than their actual definition
# [14:10] <Lachy> in other words, if we a have a <foo> element, what's the benefit of introducing a <bar> element with exactly the same semantics, and less compatibility?
# [14:10] <Grauw> the benefit of h is that you don't have to match against h1|h2|h3|h4|h5|h6 anymore, plus that it doesn$Bc`QU(B have a rank-indicator in it which doesn$Bc`QU(B apply, the benefit of <l> would be that it contains the line instead of delimiting it so that you can e.g. make line numbers (useful for source code), and the benefit of <separator> would be that the name more clearly reflects its function, and regardless of writing direction
# [14:10] <Grauw> for <separator> that would be true, yes
# [14:11] <Grauw> for h also, to some extent
# [14:11] <Grauw> <l> introduces something new
# [14:13] <Grauw> you can also more easily put IDs on <l> elements, to link to lines directly
# [14:14] <Lachy> <pre><span>line</span>
# [14:14] <Lachy> <span>line</span></pre>
# [14:14] <Lachy> should handle line numbers
# [14:14] <Lachy> it's also possible to get line numbers using <br>
# [14:14] <Grauw> I would personally use <h>, it$Bc`QM(Bl be CSS-ed anyway so who cares if by default it doesn$Bc`QU(B render like a <h> on current browsers
# [14:14] <Dashiva> I think not having to match h1|h2 etc is a dead end. Most people (anecdotal) use hx where x gives the right default styling
# [14:15] <Grauw> <l> is nicer than having those spans or trying to put line numbers on br
# [14:15] <Lachy> In the HTML5 model, you don't even have to match against all of h1 to h76. You're allowed to use <h1> for all headings if you wish, when combined with <section>
# [14:15] <Grauw> does an id on a br apply to the line before it or after it? etc
# [14:16] <Grauw> yes, but it is not required
# [14:16] <Grauw> never mind that last sentence, <h> would not be required either
# [14:16] <Lachy> I don't see how <l> is much better. It's just a little bit shorter
# [14:17] <Grauw> it indicates it$Bc`QT(B a line
# [14:17] <Grauw> span indicates nothing
# [14:17] <Grauw> plus line has supposedly got display:block attached to it
# [14:17] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
# [14:17] <Lachy> <pre> already indicates that white space is preserved and lines are indicated using LF
# [14:17] <Dashiva> Doesn't that make <l> simply a tiny <p>?
# [14:17] * Joins: st (st@62.234.155.214)
# [14:18] <Grauw> <pre> is bothersome because it messes up your indenting :)
# [14:18] <Lachy> I think a much better way to handle the line number issue would be with a ::line pseudo-element in CSS
# [14:18] <Grauw> besides not all cases where line breaking is important are also preformatted
# [14:18] <Grauw> a ::line pseudo-element would mess up if you make the browser window too narrow
# [14:19] <Grauw> and things would wrap
# [14:19] <Lachy> not with white-space: pre;
# [14:19] <Grauw> what if you want it to wrap
# [14:19] <Lachy> perhaps with 'pre-wrap' or other value
# [14:20] <Lachy> there's always <span>
# [14:20] <Grauw> <span> can be the solution to any inline element in HTML :)
# [14:21] <Grauw> Dashiva, the use case of <l> is pretty much the same as the use case for <br>. If you think <br> is a tiny <p>, then yes, <l> is a tiny <p> as well.
# [14:22] <Grauw> <l> is not a block-level element (I think), it just uses display: block to force a line break
# [14:22] <Dashiva> Ah, ok
# [14:22] <Lachy> since the use cases for <br> and <l> are identical, then <br> already covers most of them. Are there any more besides the line numbering that <br> can't handle well?
# [14:22] <Grauw> so you would use it inside a <p>, eg. <p><l>ld b,255</l><l>djnz $</l></p>
# [14:23] <Dave> <br> doesn't work with CSS :after content: except on Opera
# [14:23] <Grauw> I would have to think of it, I just mentioned it in passing really :)
# [14:23] <Dashiva> In that example it looks like subparagraphs, though :)
# [14:23] <Grauw> but generally spoken container elements are better than separator elements
# [14:24] <Grauw> Dashiva, <p> is maybe a bad choice :)
# [14:25] <Grauw> This then: <blockcode><l>ld b,255</l><l>djnz $</l></blockcode> ;)
# [14:25] <Grauw> (with a smiley face)
# [14:27] <Grauw> a variant of the line numbers would be also stylistic; alternating colours
# [14:27] <Dashiva> When you say line numbers, I think <ol>. Without line numbers, <ul> or <pre> or white-space:pre on e.g. <blockcode>.
# [14:28] <Lachy> Dave, that's just a browser limitation, there's nothing in CSS or HTML that prevents it from working
# [14:28] <Grauw> or styling a specific line number (through ::nth-of-type)
# [14:29] <Grauw> Dashiva I don$Bc`QU(B think that a list is the same as lines...
# [14:29] <Lachy> so what about handling backwards compatibility without relying on stylesheets? Would authors be allowed to use a combination of <l> and <br>?
# [14:29] <Dashiva> You even number them, that makes it a list if you ask me
# [14:30] <Lachy> Dashiva, simply proving line numbers doesn't make it a list
# [14:30] <Grauw> Dashiva, I think you could hardly call lines of code in a block of code a list (although they do call it a listing ;p)
# [14:30] <Dave> Lachy, I agree and it shows why we need test suites to combat such interop warts. <li> should work out of the box though,
# [14:30] <Dave> s/<li
# [14:30] <Lachy> most good editors provide line numbers and it's useful if code samples are presented with them too
# [14:30] <Dave> s/<li>/<l>/
# [14:31] <Grauw> I suppose you could deprecate <br>, and discourage people to mix <l> and <br>
# [14:31] <Lachy> Dave, I know we need test suites for helping achieve interop, I never said we didn't
# [14:32] <Grauw> in the end it is a question of browser support, if all browsers implement <l> then we can be happy and use it, if they don't then we can either add 1 line to our CSS and mutter about the unsupporting browser, or choose <br> over <l> after all in HTML6
# [14:33] <Grauw> given that it doesn't seem difficult to implement, I think it would be nice to have it
# [14:33] * Joins: sierk (sbornema@87.162.179.55)
# [14:33] <Lachy> I'll admit that <l> is a small possibility, but I'm not totally convinced
# [14:34] <Grauw> it would help if there were more use cases :)
# [14:34] <Lachy> I am, however, totally unconvinced of <h> and <separator>
# [14:34] <Grauw> I can imagine that
# [14:35] <Dashiva> For <h>, we could get the basic document hierarchy by counting all <hx> as headings, ignoring the x. And people could get the default styling they wanted without having to compromise the structure.
# [14:35] <Grauw> that is what Web Applications 1.0 says currently, yes
# [14:36] <Dashiva> So what is the proposed benefit of <h> then?
# [14:36] <Lachy> HTML5 almost does that. The numbers are still taken into account in some cases
# [14:36] <Grauw> I already mentioned this earlier, dashiva
# [14:36] <Grauw> as for <h> and <separator>, I'll see if I can make a well-prepared case for them later on, or just let it rest
# [14:36] <Grauw> they are??
# [14:36] <Grauw> only without <section>, I hope?
# [14:37] <Lachy> Dashiva, there are no use cases for <h> and <separator> that aren't already covered in HTML5
# [14:37] <Dashiva> Grauw: This? <Grauw> the benefit of h is that you don't have to match against h1|h2|h3|h4|h5|h6 anymore, plus that it doesn$Bc`QU(B have a rank-indicator in it which doesn$Bc`QU(B apply
# [14:37] <Grauw> yes
# [14:37] <Dashiva> But matching against hx is a -benefit-, it gives people useful default styling
# [14:37] <Grauw> Dashiva, you can have that with <h> too, easily
# [14:38] <Lachy> Dashiva, theoretically, so would <h> based upon the nesting of sections.
# [14:38] <Dashiva> But sometimes you want a small heading without going through the intermediates
# [14:38] <Grauw> well then your document isn't structured well :)
# [14:38] <Dashiva> Sure it is
# [14:38] <Grauw> small heading implies styling :)
# [14:39] <Dashiva> The pure presentation of a single heading does not impact on the structure
# [14:39] <Grauw> anyway, I don't think anybody disagrees on the usefulness of <section>
# [14:40] <Dashiva> Doesn't look like it
# [15:05] * Parts: sierk (sbornema@87.162.179.55)
# [15:05] * Quits: marcos_ (chatzilla@203.206.31.102) (Client exited)
# [15:07] * Joins: anne (annevk@131.211.112.135)
# [15:13] <anne> <section> makes styling harder and less efficient
# [15:13] <anne> (it also helps styling in some cases though)
# [15:40] * Quits: anne (annevk@131.211.112.135) (Ping timeout)
# [15:45] * Parts: DanC (connolly@128.30.52.30) (Client exiting)
# [15:58] * Joins: alessio (acartocci@83.225.122.170)
# [16:05] * Joins: anne (annevk@131.211.42.90)
# [16:12] * Parts: anne (annevk@131.211.42.90)
# [16:22] * Joins: anne (annevk@131.211.112.129)
# [16:24] * Quits: alessio (acartocci@83.225.122.170) (Quit: alessio)
# [16:32] * Joins: Alex_mediadvanced (alejandro@85.152.42.1)
# [16:33] * Alex_mediadvanced is now known as Alexf
# [16:36] * Quits: anne (annevk@131.211.112.129) (Ping timeout)
# [16:37] <Alexf> hi there, it's my first time here...
# [16:54] * Joins: Neovov (me@86.220.248.36)
# [16:54] * Quits: Neovov (me@86.220.248.36) (Quit: Neovov)
# [16:54] * Joins: Neovov (me@86.220.248.36)
# [16:56] * Joins: h3h (bfults@70.95.237.98)
# [17:04] <krijnh> Hi Alexf
# [17:09] * Joins: anne (annevk@86.90.70.28)
# [17:09] * Quits: h3h (bfults@70.95.237.98) (Quit: h3h)
# [17:11] <anne> ah, no chaos tomorrow
# [17:13] <mjs> hi everyone
# [17:17] <anne> morning mjs
# [17:17] <anne> well, afternoon really
# [17:18] <mjs> (morning here)
# [17:19] * Alexf is now known as alexf
# [17:20] <alexf> good afternoon (here) for everyone
# [17:20] * Quits: Zakim (rrs-bridgg@128.30.52.30) (Client exited)
# [17:22] * Quits: Neovov (me@86.220.248.36) (Ping timeout)
# [17:35] * Parts: alexf (alejandro@85.152.42.1)
# [17:44] * Joins: alexf (alejandro@85.152.42.1)
# [17:51] * Quits: Grauw (ask@202.71.92.74) (Ping timeout)
# [17:53] * Joins: h3h (bfults@66.162.32.234)
# [17:58] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
# [18:05] * anne wonders what the next feature request from Henrik Dvergsdal will be
# [18:06] <jmb> the moon, on a stick?
# [18:07] <anne> a <browser> tag that lets you embed a web browser in a page
# [18:10] <Dashiva> <exe> lets you embed a local system executable
# [18:11] <Dashiva> Finally real web applications (sort of)
# [18:14] <h3h> heh
# [18:15] <h3h> can I request a <money> tag?
# [18:15] <anne> I think we should also have <silly> as a generic container element for all these ideas... it works sort of like <object>
# [18:16] <h3h> heh :)
# [18:16] <jmb> anne: with fallback content?
# [18:16] <alexf> <money id="euro">yes please</money>
# [18:18] <Dashiva> I'd probably go for something like <money type="euro" src="bank" value="100">
# [18:20] <Dashiva> What about actually making a black box element, though? Give it a type attribute and tell browsers who don't recognize it to ignore the contents completely. That should serve all the new ideas quite well
# [18:20] * anne unsubscribes from www-html-editor
# [18:23] <hsivonen> while you are joking about money markup, the microformats community may already be on the case
# [18:23] <hsivonen> http://microformats.org/wiki/currency
# [18:24] <h3h> nice
# [18:24] <alexf> i prefer src="bank" better than target="bank"
# [18:24] * anne likes the way the microformats people hacked the URI syntax of their Wiki
# [18:26] <Dashiva> What do you mean, anne?
# [18:26] <h3h> the microformats currency proposal is terribly verbose
# [18:26] * hsivonen concludes that hCard sucks for people who have multi-token given or family names (the reason why I'm reading their wiki)
# [18:26] <h3h> the proposed markup is verbose, that is
# [18:27] <anne> Dashiva, lowercase and hyphenated
# [18:27] <anne> Dashiva, as opposed to camelCase
# [18:27] * Joins: dbaron (dbaron@207.47.10.130)
# [18:28] * Joins: tylerr (tylerr@66.195.32.2)
# [18:28] <Dashiva> Well, they use mediawiki. It does away with camelcase in most uses
# [18:28] <tylerr> Good day all.
# [18:28] <h3h> MediaWiki does Initial_caps by default
# [18:29] <Dashiva> I never liked camelcase wikis myself
# [18:29] <hsivonen> Dashiva: iirc vanilla mediawiki forces the first letter to be in the upper case and uses underscores
# [18:29] <h3h> :)
# [18:29] <Dashiva> hsivonen: They still use underscores for spaces, they just name their pages with hyphens instead of spaces
# [18:29] <anne> (whatever the case really is, it's the first wiki where I see this being used)
# [18:29] <h3h> that's why articles on wikipedia always start with an uppercase letter and have to make excuses when the actual item starts with a lowercase letter
# [18:30] <anne> Dashiva, ah, that could be ture
# [18:30] <anne> so maybe they haven't hacked it
# [18:30] <Dashiva> The first-letter uppercase thing looks hacked
# [18:30] <Dashiva> They removed the automatic page title too
# [18:30] <anne> oh, right
# [18:31] <Dashiva> Or maybe some mw developer finally sat down and implemented the dual-title code that's been wanted for so long
# [18:31] <Dashiva> (I doubt it :)
# [18:38] * Parts: alexf (alejandro@85.152.42.1)
# [19:05] * Joins: edas (edaspet@88.191.34.123)
# [19:05] * Joins: edaspet (edaspet@88.191.34.123)
# [19:05] * Quits: edas (edaspet@88.191.34.123) (Quit: Quitte)
# [19:24] * Joins: mjs (mjs@17.255.97.200)
# [19:26] <mjs> hi everyone
# [19:37] <tylerr> Morning mjs.
# [19:39] <tylerr> How's the day going?
# [19:39] <mjs> hi tylerr
# [19:39] <mjs> it's going ok
# [19:40] <tylerr> Good good!
# [19:45] * Joins: kingryan (kingryan@66.92.187.33)
# [20:00] * Quits: Hixie (ianh@129.241.93.37) (Connection reset by peer)
# [20:00] * Joins: Hixie (ianh@129.241.93.37)
# [20:01] * Joins: DougJ (doug_b_jon@74.76.23.86)
# [20:05] * Quits: DougJ (doug_b_jon@74.76.23.86) (Quit: DougJ)
# [20:06] * Joins: DougJ_ (djones4@74.76.23.86)
# [20:07] * DougJ_ is now known as DougJ
# [20:22] * Joins: chaals (chaals@213.236.208.22)
# [20:57] * Joins: primal1 (primal1@72.87.242.30)
# [21:00] * Quits: edaspet (edaspet@88.191.34.123) (Ping timeout)
# [21:01] * Joins: majk (mike@213.161.31.145)
# [21:02] * Quits: majk (mike@213.161.31.145) (Quit: shaaaaaaaaaaragagagbababaganabangabungaaaa!!!!)
# [21:55] * Parts: chaals (chaals@213.236.208.22)
# [22:05] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro)
# [22:08] * Joins: distant (opera@41.248.24.8)
# [22:11] * Parts: distant (opera@41.248.24.8)
# [22:36] * Quits: dbaron (dbaron@207.47.10.130) (Ping timeout)
# [22:58] * Parts: DougJ (djones4@74.76.23.86)
# [23:09] * Quits: Dashiva (noone@129.241.151.35) (Ping timeout)
# [23:10] * Quits: hsivonen (hsivonen@130.233.41.50) (Ping timeout)
# [23:12] * Joins: hsivonen (hsivonen@130.233.41.50)
# [23:14] * Joins: Dashiva (noone@129.241.151.35)
# [23:15] * Joins: hasather (hasather@81.235.209.174)
# [23:20] * Joins: chaals (chaals@213.236.208.22)
# [23:25] * Parts: chaals (chaals@213.236.208.22)
# [23:27] * Joins: chaals (chaals@213.236.208.22)
# [23:29] * Quits: hasather (hasather@81.235.209.174) (Ping timeout)
# [23:33] * Joins: dbaron (dbaron@207.47.10.130)
# [23:41] * Quits: kingryan (kingryan@66.92.187.33) (Connection reset by peer)
# [23:42] * Joins: kingryan (kingryan@66.92.187.33)
# Session Close: Thu Mar 29 00:00:00 2007

The end :)