/irc-logs / w3c / #html-wg / 2007-04-04 / end

Options:

# Session Start: Wed Apr 04 00:00:00 2007
# Session Ident: #html-wg
# [00:01] * Quits: mjs (mjs@17.255.98.91) (Connection reset by peer)
# [00:01] * Joins: mjs (mjs@17.255.98.91)
# [00:04] * Quits: heycam (cam@203.214.79.176) (Ping timeout)
# [00:04] <Zeros> Hixie, seems like it'd make the most sense to create smaller task groups of 10 or fewer people to hand each issue; they'd come to a consensus and present their findings on the issue (practicality,benefits,etc.) back to the group where anyone who feels they have a sufficiently strong counter argument can present it.
# [00:04] <Zeros> handle
# [00:04] <Hixie> sounds like a lot of work
# [00:04] <Zeros> Better than letting one person do it which creates huge bias
# [00:04] <mjs> I would expect ad-hoc task groups would form
# [00:05] <mjs> currently there sort of is one for <video> in WHATWG, based on people who care
# [00:05] <mjs> and a self-selected one for the Design Principles document in HTML WG
# [00:06] <Hixie> oh well sure, unofficial ones... they don't "report back", though, they just do the work.
# [00:07] <Zeros> The issue I see is that even if they do all the research about the topic, its still biased as to what they researched in the first place and what they interpreted from the research.
# [00:07] <Zeros> in reference to "who's responsibility
# [00:07] <Zeros> is to take all feedback from all the sources I listed in an earlier e-mail
# [00:07] <Zeros> (including blogs, forums, direct feedback from implementors, comments in
# [00:07] <Zeros> bug systems, conclusions from relevant"
# [00:09] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
# [00:18] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
# [00:30] * Joins: heycam (cam@130.194.72.84)
# [01:04] * DanC is away: family time
# [01:18] * Quits: tylerr (tylerr@66.195.32.2) (Quit: Leaving)
# [01:21] * Joins: htmlr (htmlr@203.206.237.84)
# [01:34] * Parts: hasather (hasather@81.235.209.174)
# [01:34] * Quits: mjs (mjs@17.255.98.91) (Connection reset by peer)
# [01:35] * Joins: mjs (mjs@17.255.98.91)
# [01:36] <anne> +1 to dropping the +1 one
# [01:39] * Quits: htmlr (htmlr@203.206.237.84) (Ping timeout)
# [01:40] <Dashiva> You're not helping the cause, anne ;)
# [01:41] <mjs> my own feelings on the subject:
# [01:41] <mjs> -1 on +1
# [01:41] <anne> heh
# [01:41] <Hixie> 0?
# [01:41] <Hixie> or do you mean -1 over +1, as in -1/+1, which is -1?
# [01:41] * anne deletes some codec discussion
# [01:42] <mjs> so what would you guys think of turning "Mostly Semantic Markup" into "Separation Of Concerns"
# [01:42] <mjs> that might capture the real point better, in addition to placating Murray (though I am not sure I get his point still)
# [01:42] <Hixie> without changing the text of the principle?
# [01:43] <mjs> well, with light editing to match the new name
# [01:43] <Hixie> sure
# [01:43] <mjs> Enable Separation Of Presentation From Content would be a bit unwieldy
# [01:44] * anne agrees with Hixie that at some point the group needs to decide on by-argument versus by-majority
# [01:44] <anne> SeparatePresentionContentAndBehavior
# [01:44] <Hixie> i find it quite amusing given that HTML5 currently very carefully sidesteps the / issue by defining them semantically without breaking their presentational meaning
# [01:44] <Hixie> avoid talking about Behaviour
# [01:44] <Hixie> nobody knows what that is
# [01:45] <Dashiva> It's :hover
# [01:45] <anne> everything that involves events...
# [01:45] <anne> but then <a> would violate it so nm
# [01:45] <Hixie> i rest my case (you both gave totally different answers)
# [01:46] <Philip> anne: But which decision method should the group use to decide which decision method to use?
# [01:46] <Dashiva> I just bring up :hover whenever the case comes up because CSS fanatics don't seem to mind it even though they cry about separating out behavior
# [01:46] <Hixie> some css fanatics
# [01:46] <Hixie> don't lump us all in that bucket
# [01:47] <Hixie> i personally think all the discussion about "separating behaviour" is one by red herring
# [01:47] <Hixie> s/by/big/
# [01:47] <Philip> If the majority thinks by-majority is best, but the best arguments come in favour of the by-argument side, it'll get a bit stuck
# [01:47] <anne> Philip, benevolent dictator
# [01:48] <Dashiva> Hixie: I don't consider people in your bucket fanatics
# [01:48] <mjs> all we have to do is replace event handler attributes with xml events
# [01:48] <mjs> then all behavior problems will be solved
# [01:48] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [01:49] <anne> That would imply that introducing new stuff actually solves problems with existing technology...
# [01:49] <anne> Sounds awesome!
# [01:50] <anne> Philip, http://www.w3.org/mid/Pine.LNX.4.62.0704031953420.4736@dhalsim.dreamhost.com elaborates on that
# [01:50] <Hixie> anyone able to find text in HTML4 that says you should ignore <td> tags when they're not in a <table>?
# [01:51] <anne> ooh, SVG 1.1 errata
# [01:51] <anne> Hixie, I think the IE guys already acknowledged that as a bug
# [01:51] <mjs> by-argument invites the question of who decides what arguments are best
# [01:51] <anne> at least one of them did, iirc
# [01:52] <anne> mjs, the benevolent dictator
# [01:52] <mjs> I would say the person responsible for taking action (most likely the editor of a relevant spec) should make the initial decision
# [01:52] <mjs> and for lack of a better policy, vote of the group can override if someone calls for one
# [01:52] <mjs> hopefully votes will be unwieldy enough to be used very rarely if ever
# [01:52] <anne> that sounds reasonable enough
# [01:53] * anne wonders why Murray is so hung up on +1 and -1
# [01:53] <mjs> votes would hopefully also be preceded by reasoned discussion
# [01:55] <Hixie> the problem with votes (not that i oppose them, just mentioning this) is that if the person making the decision hasn't yet made a new decision based on new arguments, but made a decision on old arguments, the vote can force the issue before the new arguments are considered
# [01:55] <hsivonen> mjs: what I tried to get at Re: semantics was that defining reasonable presentation for different media is good enough and precise semantics aren't that important
# [01:55] <Hixie> e.g. i have thousands of outstanding comments on HTML5 still to deal with, all of which have so far been "ignored", and people who raised them might think that i'm ignoring their feedback, and so might want to raise a vote
# [01:56] * Joins: karl (karlcow@128.30.52.30)
# [01:56] <mjs> hsivonen: I think different people have different exact views on this matter, and it's kind of hard to capture
# [01:56] * Joins: htmlr (htmlr@138.130.176.60)
# [01:56] <mjs> I think what we want to express is that HTML isn't gonna be XSL-FO, but we're not overly dogmatic about semantics
# [01:57] * Joins: gavin (gavin@74.103.208.221)
# [01:57] <anne> we don't want to repeat HTML 3.2 either i think
# [01:57] <anne> (although the focus HTML 3.2 had on implementors was prolly good)
# [01:57] <mjs> Hixie: I think issues should be discussed before voting is even considered, and arguments should be raised and given time to be considered before calling for a vote
# [01:57] <hsivonen> nor become DocBook or TEI
# [01:57] <mjs> Hixie: and also having a soft agenda of topics to discuss on-list might help people respect the queueing
# [01:58] <mjs> Hixie: like saying "this month we will mostly discuss media elements, next two weeks after will be canvas" or something along those lines
# [01:58] <Hixie> mjs: fair enough
# [01:58] <mjs> obviously people can make a comment any time they want but should have less expectation of active discussion when it's not one of the focus topics
# [01:59] <h3h> that kind of schedule would be awesome
# [01:59] <anne> yeah, it would be useful if Hixie put his rough agenda somewhere in the draft again I think
# [01:59] <h3h> but it assumes that there's some definitive list of issues to go through
# [01:59] <hsivonen> I believe I have a number of comments in Hixie's queue and I've learned to route around the unresolved issues
# [02:00] <hsivonen> nn
# [02:00] <anne> g'night hsivonen
# [02:01] <mjs> adding issues to a pool to be enqueued could be a distributed task, though I dunno how much anyone would enjoy doing it
# [02:01] <Hixie> my schedule for the next quarter is <video>/<audio>, investigate adding something like the old <switch> proposal, and respond to 1000 feedback e-mails and fix 10 red issue boxes.
# [02:02] <Hixie> for what that's worth.
# [02:03] <anne> hmm, <option> is dropped indeed
# [02:03] <anne> in html5lib that is
# [02:04] <karl> http://www.searchtools.com/tools/tools-opensource.html to remember for testing
# [02:04] * Joins: Lachy (chatzilla@58.105.240.232)
# [02:14] * Quits: h3h (bfults@66.162.32.234) (Quit: |)
# [02:18] * Quits: Lachy (chatzilla@58.105.240.232) (Quit: Chatzilla 0.9.77 [Firefox 2.0.0.3/2007030919])
# [02:22] * Quits: anne (annevk@81.68.67.12) (Ping timeout)
# [02:24] * Joins: Lachy (chatzilla@220.245.91.147)
# [02:30] <Hixie> unsigned short is what, 8 bits or 16 bits?
# [02:31] <mjs> in C? 16 bits
# [02:31] <mjs> in IDL, I think also 16 bits
# [02:31] <Hixie> thanks
# [02:32] * Joins: olivier (ot@128.30.52.30)
# [02:32] * Quits: marcos (chatzilla@131.181.148.226) (Ping timeout)
# [02:32] * Hixie is wondering whether to use the extra bits in the error value for further expansion, and ask people to do bitmask maths to find the error kind, or ask them to look for ranges of values; or, whether that's doomed and expansion will have to be in a separate field if we do it
# [02:33] * Joins: marcos (chatzilla@131.181.148.226)
# [02:34] <mjs> using short in an API is rarely beneficial
# [02:35] <Hixie> oh i wasn't checking for that
# [02:35] <Hixie> i was considering the bit mask idea and needed to know how many bits i had to put in the mask's value
# [02:36] <Hixie> 0xF000 vs 0xF0
# [02:36] <Hixie> or similar
# [02:36] * Joins: htmlr_ (htmlr@203.206.237.84)
# [02:36] <mjs> I'm not sure what you want to store in the error object
# [02:36] <Hixie> right now it just has the kind of error -- aborted, network, or decode.
# [02:37] <Hixie> it could have more, e.g. http-404, dns-failed, etc
# [02:37] <Hixie> resource-was-video-but-i-was-expecting-audio
# [02:37] <mjs> but one design that tends to be workable is to have a numeric code for the error domain (with known constants), a numeric value within that domain, a string description, and maybe optional extra data
# [02:37] * Quits: htmlr (htmlr@138.130.176.60) (Ping timeout)
# [02:37] <mjs> I think really detailed error reporting may be overkill though
# [02:37] <mjs> aborted, network, decode seems like an ok starting point
# [02:37] <Hixie> yeah, right now it's just aborted, network, or decode.
# [02:37] <Hixie> i was just considering expansion options for future versions
# [02:39] <mjs> if you want to make it expandable then probably making it an object rather than a primitive value is sufficient
# [02:40] <Dashiva> I don't think xhr has more detailed than a catch-all NETWORK_ERR
# [02:40] <Hixie> mjs: yeah that might work, just worried that that's too heavy duty.
# [02:40] <Hixie> we'll worry about changing error later.
# [02:40] <Hixie> i'll note it as an issue.
# [02:54] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
# [02:54] <karl> hmm I wish browsers had a feature save as... valid xhtml/html
# [02:55] <Dashiva> hehe
# [02:56] <Dashiva> With (X)HTML5 defined serializations, that might become reality
# [02:56] * Joins: h3h (bfults@70.95.237.98)
# [02:59] * Quits: h3h (bfults@70.95.237.98) (Quit: h3h)
# [03:00] <mjs> it might not always be possible to make the document valid without altering presentation/behavior
# [03:00] <mjs> (for example nesting blocks in inlines)
# [03:11] * Quits: Dashiva (noone@129.241.151.35) (Quit: Dashiva)
# [03:12] * Joins: h3h (bfults@70.95.237.98)
# [03:13] * Joins: sbuluf (hem@200.49.140.228)
# [03:14] * karl wonders if henri went ahead with wiki page for XTech ?
# [03:15] <karl> maybe it should be on PeopleLocation page, more than creating a one time page
# [03:15] <karl> http://esw.w3.org/topic/PeopleLocation hmm I wonder
# [03:16] <karl> or something like
# [03:16] <karl> http://esw.w3.org/topic/HTML/BOF
# [03:16] * Joins: Dashiva (noone@129.241.151.35)
# [03:18] <karl> ooooh
# [03:18] <karl> http://esw.w3.org/topic/HTML/XTech2007BoF
# [03:18] <karl> I see
# [03:24] * Quits: kingryan (kingryan@66.92.187.33) (Quit: kingryan)
# [03:37] * Quits: mjs (mjs@17.255.98.91) (Quit: mjs)
# [03:42] * Joins: mjs (mjs@17.255.231.74)
# [03:47] * Quits: mjs (mjs@17.255.231.74) (Quit: mjs)
# [03:52] * Lachy wonders whether the decision of by-consensus vs. by-argument, should itself be determined by consensus or argument?
# [03:55] <marcos> hehe
# [03:57] <karl> Lachy: THAT is meta.
# [03:57] <Lachy> karl: what do you mean?
# [03:58] <karl> hmmm I guess the joke didn't go through
# [03:58] <karl> this is a meta discussion
# [03:58] <sbuluf> that it is a meta-level
# [03:58] <karl> yep
# [03:58] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [03:58] <sbuluf> an interesting one, certainly
# [03:59] <Lachy> ok, just wasn't sure what you meant by meta
# [03:59] <karl> and that is interoperability problems ;)
# [03:59] <sbuluf> heh =P
# [03:59] <marcos> lachy, perhaps you should express yourself in OWL
# [04:00] * karl doesn't like the block/inline model for HTML.
# [04:00] <Philip> I think the solution is to have the chair(s) decide, no matter how much fun infinitely recurring mailing list threads would be :-)
# [04:00] <karl> hehe
# [04:01] * marcos notices the beginings of another +1 usage debate in email :(
# [04:01] <Lachy> Philip: +1
# [04:03] <sbuluf> yesterday i wondered here if there were off limits topics to this working group (notably, back compat issues), or if everything was discussable. the answer at least some gave, was that everything was discussable...but that some players might leave if back compat, for instance, was broken
# [04:04] * Joins: gavin (gavin@74.103.208.221)
# [04:04] <sbuluf> that, imho, points to by-consensus.
# [04:06] <Lachy> sbuluf: there's a difference between something that discussable and debatable. Everything can certainly be discussed, but there are just some things (like back compat) which just aren't up for debate because they are such fundamental goals
# [04:07] <Lachy> also, I don't see how anything you said points to by-concensus
# [04:07] * Joins: Zeros (Zeros-Elip@69.140.48.129)
# [04:07] <sbuluf> lachy, well...that's exactly why i asked yesterday about it here. you might be interested even in checking the log, perhaps. mjs, and anne, at least, seemed to think that everything was discussable (which was *not* my impression really.
# [04:08] <Lachy> sbuluf: can you find and highlight the relevant section in the log for me?
# [04:09] <sbuluf> lachy, probably, yes, give me a sec
# [04:14] <sbuluf> http://krijnhoetmer.nl/irc-logs/html-wg/20070403#l-302
# [04:14] <sbuluf> lachy, i think it starts there
# [04:16] <Lachy> ok, I'll read it later
# [04:16] <sbuluf> sure
# [04:17] <sbuluf> karl, what's wrong with the block/inline model in HTML? and what would be an alternative?
# [04:20] <Lachy> ah, the block-vs-inline debate is an interesting one, but the pragmatic side of me doesn't think it needs to be rehashed
# [04:24] * Quits: Philip (excors@80.177.163.133) (Quit: Philip)
# [04:24] <sbuluf> i'm ignorant, myself. i'm sure there might be finer points that i miss.
# [04:25] <sbuluf> i tend to see things from an end-user point of view. and as such, the idea of block sounds like enclosing bigger structures in markup, while the inline one means to enclose just little chunks of text. as such, seems like a simple, graspable idea.
# [04:26] <karl> sbuluf: bloc/inline is a kind of thing inherited from typography.
# [04:27] <karl> the problem is that many elements of HTML should not be either block or inline
# [04:27] <karl> the good examples is code and blockquote/q
# [04:27] <karl> when we have elements which are used to give meaning to the content.
# [04:27] <karl> the fact to be block or inline should not matter at all
# [04:27] <karl> because it is not related
# [04:28] <karl> so because we have block/inline, people try to hack on top of it
# [04:28] <karl> and we have to create things like... blockcode
# [04:28] <karl> it is insane somehow
# [04:28] <karl> to have to create new elements just because of block/inline
# [04:29] <sbuluf> mm, karl, thanks. i think i start to see what you mean. not completely sure, but i think is a start.
# [04:30] <sbuluf> do you mean something like the semantic and thepresentational aspects get mixed up?
# [04:30] <karl> something like that.
# [04:31] <sbuluf> i think i see, thanks.
# [04:31] <Lachy> there was an interesting thread on www-html back in 2004 (I think) that covered all the arguments for and against block vs. inline
# [04:31] <karl> there are html elemts which are outside of this block/inline model
# [04:32] <karl> and I think all the elements which carries only meaning should be outside of block/inline.
# [04:35] <karl> Lachy: good memory
# [04:35] <karl> http://lists.w3.org/Archives/Public/www-html/2004Jul/0015.html
# [04:35] <sbuluf> thanks both =P
# [04:37] <karl> and http://lists.w3.org/Archives/Public/www-html/2004Jul/thread.html#msg49
# [04:38] <Lachy> http://lists.w3.org/Archives/Public/www-html/2003Dec/0123.html
# [04:38] <Lachy> that's actually the message I was thinking of
# [04:41] <karl> oh yes even better
# [04:45] <sbuluf> i'm reading. and probably will be wise to chew it up a bit before saying much.
# [04:46] <Lachy> it's interesting to re-read stuff I wrote 3 ago, and even though it's talking about XHTML2, it still seems quite good :-)
# [04:47] <sbuluf> i feel that sometimes too. sometimes, the first impressions are keenest.
# [04:52] <sbuluf> do you ever use the trick of analyzing how our minds perceive/organize the information in a document, by imagining a document ina foreing language, as seen from afar?
# [04:53] <sbuluf> don't we organize it first by identifying "chunks"?
# [04:56] <karl> sbuluf: there are definitely surprising things when you look at other languages
# [04:57] <karl> examples
# [04:57] <karl> http://www.la-grange.net/2006/02/04-3810-japon-texte-1.jpg
# [04:57] <karl> http://www.la-grange.net/2006/02/04-3811-japon-texte-1.jpg
# [04:57] <karl> http://www.la-grange.net/2006/02/04-3812-japon-texte-1.jpg
# [04:57] * karl is going to lunch
# [05:01] <sbuluf> (just for the record, even if top-to-bottom instead of left-to-right, i still see chunks)
# [05:04] <Lachy> someone please explain to Brad Fults (on the mailing list) that it's ok for specs themselves to be numbered, but that is completely different from versioning in the language
# [05:04] * Lachy is going to lunch
# [05:14] <h3h> no need to explain
# [05:14] <h3h> it was a passing observation
# [05:15] <h3h> and stated quite clearly in question form
# [05:15] <Zeros> We should just go with HTML-TR2010 (HTML Technical Revision 2010) or some such
# [05:16] <Zeros> all the major/minor versioning, even for the spec itself, seems unnecessary.
# [05:19] <h3h> don't tell Lachy that :P
# [05:42] <Lachy> h3h, I didn't realise you were Brad
# [05:42] <h3h> I hope that doesn't cause you to censor yourself :)
# [05:42] <Lachy> Zeros: it would be silly to include the year in the name, especially when it's highly unlikely that HTML5 will actually be finished by 2010
# [05:43] <Lachy> h3h: I never censor myself
# [05:43] <h3h> good
# [05:45] <Zeros> Lachy, the year would be decided when we publish it as a REC
# [05:45] <Zeros> not now
# [05:46] <Lachy> it's still silly to put it in the title
# [05:46] * marcos hopes he can finish reding the 40+ page HTML5 spec by 2010!
# [05:46] <Lachy> just like it was silly to put the year in the namespace URI
# [05:46] <marcos> s/reding/reading
# [05:46] <Zeros> Lachy, Why? Its a unique identifer, other wise we end up with HTML6 and then HTML7 and what about a minor change of HTML6.251
# [05:46] <h3h> yeah, years are a bad idea for a spec that's supposed to be definitive for years to come
# [05:46] <Zeros> 4.01, XHTML1.1
# [05:47] <h3h> I'd be fine with HTML 5.0
# [05:47] <Lachy> numbering incrementally is sufficient
# [05:47] <Zeros> h3h, the year has to do with publication, it differentiates if from a later revision
# [05:47] <h3h> Zeros: that's what the "latest version" and "previous version" etc. links are for at the top of all W3C published docs
# [05:47] <Zeros> It doesn't change validity at all 10 years from now, nor does HTML5 since anyone can lookup the publish date anyway
# [05:48] <h3h> years make people want to upgrade. years are good for consumer products like MS Office
# [05:48] <Zeros> h3h, once its made into a REC that's the last version, I don't think we should be calling this HTML5
# [05:48] <Zeros> what do we call the XHTML serialization of ti?
# [05:48] <Zeros> s/ti/it/
# [05:48] <h3h> that's the last version? somehow I doubt that
# [05:49] <Zeros> h3h, the REC is the last version of that spec
# [05:49] <h3h> the language, like the world, will continue to evolve even after this wg is done
# [05:49] <Zeros> that would be a different revision
# [05:49] <h3h> sure, then the next one is 6.0...
# [05:49] <Zeros> h3h, or 5.2
# [05:49] <h3h> sure if it's a minor revision or whatever
# [05:49] <Zeros> we had 3.2 and then 4.01
# [05:49] <h3h> the corresponding XHTML version number is another good question
# [05:49] <Zeros> why do we need minor and major versions, and who decides that's minor and major?
# [05:50] <h3h> if that even deserves a name+version number
# [05:50] <h3h> I'm guessing not
# [05:50] <h3h> there's just HTML-as-HTMl and HTML-as-XML
# [05:50] <sbuluf> the years-in-url's general rationale, if i understood correctly, is because a domain can be reassigned to a new authority, eventually, and this helps identify when a certain url was issued, and who was the authority then (i'm not saying i vouch the idea, though)
# [05:50] <Zeros> h3h, That's not real helpful, then people make up names and terms.
# [05:51] <h3h> possibly
# [05:51] * Joins: mjs (mjs@64.81.48.145)
# [05:52] <karl> [12:46] <Lachy> just like it was silly to put the year in the namespace URI
# [05:52] <karl> Lachy: dates in URI are not always dates :)
# [05:52] <karl> dated space is a very useful way of creating unique identifiers. :)
# [05:54] <sbuluf> and unique-in-long-time-periods (i.e, "eternal"), even if authority changes, is what i meant
# [05:55] <Lachy> karl: what are they if they're not dates?
# [05:56] <Lachy> I'm glad the new namespace policy says to use /ns/ instead of /YYYY/
# [05:59] * Joins: zcorpan (zcorpan@130.243.79.10)
# [06:01] <karl> Lachy: I just said it a way to create unique identifiers.
# [06:03] <karl> just think about a system of creating unique identifiers in an information space.
# [06:03] <karl> which is practical and easy
# [06:03] <mjs> http://esw.w3.org/topic/HTML/ProposedDesignPrinciples -- thoughts on "Separation of Concerns" as replacement for "Mostly Semantic Markup"?
# [06:04] <sbuluf> i have some strong opinions about it, but probably exceeds what would be useful to discuss here (karl, we have discussed some of them before, you know me as Biblio in freenode, and as fernando franco in the TAG mailing list)
# [06:04] <Lachy> I disagree. Dates in URIs are useful for identifying the date of publication for articles, specs, etc. But when the date has no relevance, it's pointless
# [06:04] * Quits: zcorpan (zcorpan@130.243.79.10) (Ping timeout)
# [06:04] <marcos> +1
# [06:04] <karl> Lachy: forget about the date :)
# [06:05] * mjs gives marcos a dirty look
# [06:05] <marcos> hehe
# [06:05] <karl> and design a system to create unique identifier
# [06:05] <Lachy> mjs: +1
# [06:05] * mjs sighs
# [06:05] <Lachy> -1
# [06:05] * Joins: zcorpan (zcorpan@130.243.79.10)
# [06:06] <karl> mjs: why don't you just leave Separation of Concerns
# [06:06] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [06:06] <karl> do not create camps, but just build argumentation on what you want
# [06:06] <karl> a double title leads to argument
# [06:07] <mjs> karl: it's in the Disputed section because the past version was disputed
# [06:07] <karl> :)
# [06:07] <karl> yes but the dispute is about a topic
# [06:07] <mjs> karl: I try to reflect multiple points of view when there is not consensus
# [06:08] <mjs> (although I hope the latest version can sustain a broader consensus)
# [06:09] <karl> http://esw.w3.org/topic/MeaningVsBehavior
# [06:09] <karl> which is specifically a bad example :p
# [06:09] <karl> topic 1 vs topic 2
# [06:09] <karl> :)
# [06:10] <Zeros> MeaningAndBehavior would probably be better
# [06:10] <karl> yep Zeros indeed
# [06:10] <mjs> karl: the "vs" only reflects cases where we haven't yet settled on a principle, it is not intended to be lasting
# [06:10] <mjs> karl: I would prefer to reflect substantive disagreement than to only push my own point of view
# [06:10] <sbuluf> http://www.teoriadetodo.com.ar/fips/specs/cdl/anatomy.htm <--some of you might find some value to this topic here
# [06:11] <karl> mjs: I agree with you on the desire to illustrate the two points of view
# [06:11] <karl> I can't find the reference in wikiwikiweb
# [06:11] * Joins: zcorpan_ (zcorpan@130.243.79.10)
# [06:11] <karl> about the patterns for discussions
# [06:11] * Joins: gavin (gavin@74.103.208.221)
# [06:11] <karl> :)
# [06:12] <mjs> I can say "or" instead of "vs"
# [06:12] * Quits: zcorpan (zcorpan@130.243.79.10) (Ping timeout)
# [06:12] <mjs> but I'm not sure that is any better
# [06:12] <karl> maybe there is a meta category to this two names
# [06:12] <karl> these
# [06:13] <sbuluf> to identify and properly categorize and name design goals, is not an easy task
# [06:13] <Zeros> I'd rather use "And" since it implies both topics are being discussed there rather than its a battle between the two.
# [06:13] <sbuluf> i've done a little of that myself, and is definitely not easy
# [06:14] <mjs> Zeros: well, when there's mutually exclusive alternatives, it's hard to dress it up
# [06:14] <karl> there are elements for structure (table), meaning only (code), functionalities (form, head), style (b), etc.
# [06:15] <Zeros> mjs, yeah. Really I don't think its all /that/ important as long as its more descriptive than DeclWebFormExpr
# [06:15] <karl> and I'm pretty sur if we were drawing circles around each element (as in tagging them with category), we would have different drawings depending on the people
# [06:16] <mjs> I probably should have said something about how it's best for an element to have both a meaning and a default presentation
# [06:17] <karl> mjs: I see how it can help, but I see the drawback as well.
# [06:17] <Zeros> default presentation in the abstract sense
# [06:17] <sbuluf> karl, don't you find my approach cleaner? particularly, from the url above... "CDL cleanly separates content, from presentation, from structure, from semantics, from behaviour"
# [06:17] <karl> example: blockquote used for indenting text
# [06:17] <Zeros> I don't think we should specify it, we can't possibly make it work for all UAs
# [06:18] <karl> we may guess that blockquote has been abused because of the presentation
# [06:19] <Zeros> mjs, where does Webkit currently content sniff documents to figure out the mime?
# [06:20] * karl is looking at sbuluf link
# [06:22] <mjs> Zeros: content sniffing is in the network layer we use on Mac OS X
# [06:22] <karl> s/semantics/meaning/ would be better in the document, I guess. but there is an idea indeed. and still, I'm pretty sure we all have a different opinions of what convey meaning or not.
# [06:23] <karl> structure is very often inherited from paper typography, which has its limits in web world.
# [06:23] <mjs> I think it comes down to how you would describe the difference between HTML and a pure visual formatting language like PDF
# [06:23] <sbuluf> semantics would be more technically precise, yes, i used meaning since is easier for end-users, hence good for reducing learning curve
# [06:23] <karl> meaning is better than semantics.
# [06:23] <karl> less confusion
# [06:24] <sbuluf> karl, by structure, i mean just "a bunch of [ordered] fields (i.e, label/value pairs
# [06:24] <karl> but I really appreciate the work of mjs, I think it is a very valuable work which is done right now
# [06:25] <karl> aka The Design Principles
# [06:25] <sbuluf> i think to clearly state design goals is totally vital
# [06:25] <Zeros> mjs, What is it using to content sniff the <object> then, the file extension? My local test has Safari showing the source when its sent as text/plain, though the file extension isn't html anymore.
# [06:25] <mjs> how would you guys describe the difference between HTML and PDF? (other than the fact that PDF is a binary format - in theory it could be an XML grammar)
# [06:26] <mjs> Zeros: it sniffs based on content, not filename
# [06:26] <sbuluf> pdf is a language for printers, not a content authoring format
# [06:26] <karl> mjs: PDF is a graphical format
# [06:26] <Zeros> mjs, the content of the file is an html document, still shows the source.
# [06:27] <sbuluf> imho, pdf should not even exists, and html/css should cover printing decently, instead
# [06:27] <karl> when you copy and paste a PDF text, the whole structure and meaning of the document is jumbled.
# [06:27] <Zeros> karl, That's not quite true since PDF has annotations and extra metadata in tags now
# [06:27] <mjs> people make WYSYWIG tools to edit PDF
# [06:27] <sbuluf> no lossless conversion, exactly
# [06:27] <mjs> and it can be viewed interactively
# [06:27] <mjs> and even supports hyperlinks
# [06:28] <sbuluf> no lossless conversion, exactly <--this turns into an *output* format
# [06:28] <Zeros> You could certainly write something that copy and pastes the pdf as is karl
# [06:28] <karl> I guess it might be possible to create a logical flow in PDF, but each time I have tried to cut and paste document, with Apple Preview for example
# [06:29] <karl> I ended up with a text making a poetic mixing of all paragraphs and lines
# [06:29] <sbuluf> it never works, and exporting back to other formats, does not work either, no lossless conversion
# [06:30] <Zeros> that doesn't work with HTML either
# [06:30] <mjs> RTF is another good example for comparison
# [06:31] <mjs> (cutting and pasting from it does not jumble logical flow, but it is much more presentational than HTML)
# [06:31] <karl> I wonder if CSS 3 layout implemented in wysiwyg tools will give the same problems.
# [06:31] <karl> like for tables
# [06:31] <sbuluf> txt, rtf, pdf...it is 2007, and we still do not have a half decent content authoring language
# [06:32] <sbuluf> html+css should be the best, and only one (what so many for?), but it has serious flaws
# [06:32] <karl> sbuluf: it is only 30 years ;) peanuts
# [06:32] <Zeros> How do you represent HTML on the clipboard to preserve the logical flow? As rendered with styles the flow the user sees may not be the document order.
# [06:32] <sbuluf> kerl =P
# [06:33] <sbuluf> zeros..ahh...html and wysiwyg editing, a broken topic these days
# [06:33] <karl> I think we will not succeed thinking like that.
# [06:33] <mjs> I think we're wandering off topic
# [06:33] <mjs> or at least, my point wasn't to talk about why everything sucks
# [06:33] <mjs> but rather, what's different about HTML than other rich hypertext formats
# [06:33] <karl> we may have to think in terms of what the language can help us to do in certain contexts, having in mind that it can be always abused
# [06:34] <Zeros> sbuluf, you said "no lossless conversion, exactly" in response to karl's comment on the jumble when pasting
# [06:34] <karl> and being abused is somehow a feature.
# [06:34] <Zeros> sbuluf, HTML has the same problem since the semantics (meaing) in the document are generally lost when pasting elsewhere
# [06:34] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [06:34] <Zeros> you do lose something
# [06:34] <sbuluf> the wg charter mentions editing API's and WYSIWYG editing tools, right? i wonder how seriously that is being considered. and if it should not even be included in mjs's design goals list
# [06:35] <karl> mjs: do you have contacts with iWeb?
# [06:35] <sbuluf> mm, zeros, have you seen the link i posted above? it might (or might not) be of relevance for this as well
# [06:35] <karl> iWeb Team
# [06:35] <mjs> karl: some
# [06:35] <karl> it would be good to have them on the group
# [06:35] <Zeros> sbuluf, for that other document language; CDL?
# [06:35] <sbuluf> zeros, yes.
# [06:35] <mjs> if the follow-up question is "can I influence the kind of markup they generate?" then the answer is "only very indirectly"
# [06:36] <karl> the question was can you make them participate
# [06:36] <Zeros> sbuluf, its an interesting idea, looks an awful lot like RDF
# [06:36] <karl> authoring tools are essential
# [06:36] <Zeros> sbuluf, very abstract
# [06:37] <sbuluf> zeros, the "meaning" part should be rdf like. but the rest should be a sort of functionality like what html does today
# [06:37] <mjs> I'm not sure any of them are sufficient experts on web technology to usefully participate
# [06:37] <sbuluf> zeros, totally empty, in fact. just full of hooks
# [06:38] <karl> mjs: could you try to invite them to participate or if you give me a contact person, I can invite them.
# [06:39] <Zeros> sbuluf, Well, speaking just for me, RDF is very complicated and very abstract. Too much so to be of any use to a general editor which is what we seem to be targeting with the HTML WG. If we went with that much abstraction I think we'd be making a mistake. I mean, if we used 100 lines of XML and pronunciation keys and definitions and logical flow languages all bundled together we could certainly get more meaning into a single document than HTML does.
# [06:39] <Zeros> it'd just be unwieldy
# [06:39] <karl> mjs: I also see that Pages can export as html. Another case that would be useful. Another team of people.
# [06:39] <mjs> karl: I can spread the word to them, but like I said, I'm not sure they would have a lot to add
# [06:40] <mjs> HTML to them is an export format used for presentation-oriented final delivery on the web
# [06:40] * Quits: zcorpan_ (zcorpan@130.243.79.10) (Ping timeout)
# [06:40] <karl> I think at least it could help to build more awareness for them
# [06:40] <karl> on the correct things to do.
# [06:41] <Zeros> I'd be pretty cool if TextEdit exported more semantic markup. It already generates a valid HTML4 skeleton document which is nice.
# [06:41] <karl> and they may have questions that we didn't think about
# [06:41] <mjs> we do talk to them about their HTML export related issues
# [06:41] <mjs> and gave some suggestions for improving their markup and styling
# [06:41] <karl> with knives and hammers ?
# [06:41] <karl> WOW style negotiations?
# [06:41] <mjs> but iWeb and Pages are not (yet) major web content authoring tools
# [06:42] <mjs> would be more interesting to have folks who work on Dreamweaver or similar
# [06:42] <karl> yes
# [06:42] <karl> I wish Adobe was part of the WG.
# [06:42] <mjs> I believe Adobe is involved in the CSS WG so that wouldn't be out of the question
# [06:42] <karl> I'm trying on this side too
# [06:42] <sbuluf> mjs, should the whole wysiwyg editability topic be included in the design goals list as well? is it a design goal?
# [06:43] <mjs> sbuluf: I think of support for editing APIs as a required feature, not a design goal
# [06:43] <Zeros> I know a couple people over at Adobe, I could drop hints at the conference in June, but I don't think anyone related to DW will be there.
# [06:43] <mjs> top missing participants I'd like to see involved:
# [06:44] <mjs> Microsoft, Adobe, Nokia, BM, Sun
# [06:44] <mjs> (that should be IBM, not BM)
# [06:45] <Zeros> MS should be joining eventually?
# [06:45] <Lachy> Zeros: Chris Wilson from MS will be the Chair
# [06:46] <Lachy> so yes, eventually
# [06:46] <Zeros> Lachy, So I've read, but there doesn't seem to be any development on that.
# [06:46] <Lachy> DanC: was going to follow up on it I think
# [06:47] <Zeros> cool
# [06:48] <sbuluf> i can not help but to wonder how many people, and how seriously have given thought to the wysiwyg editability problem
# [06:48] <Lachy> lots of people have thought about it, few people think about it correctly and even fewer even try to implement it sensibly
# [06:49] <sbuluf> i thouht about it some, and i found it might be just about impossible, with html as it stands today
# [06:49] <Lachy> why
# [06:50] <sbuluf> i don't think i could make a bullet list right now, but my general feeling, is that html simply was not developed, over time, keeping that topic as a design goal
# [06:50] <sbuluf> and hence html+css have become too complex for sensible wysiwyg editability
# [06:50] <Zeros> Lachy, lack of mind reading technology and neural nets. Software that's powerful enough to ascertain the meaning of the content you're typing and then add the proper elements to pull it off remains to be seen.
# [06:51] <Zeros> Styling it is also problematic because browsers all render differently. How do you write a wysiwyg tool that works around bugs in all the browsers and still provides what the user wanted?
# [06:52] <Lachy> Zeros: it doesn't require anything nearly that complex. It just requires suitable interfaces for the user to tell the editor what the content is
# [06:52] <sbuluf> i agree
# [06:52] <Zeros> Lachy, And then style it how?
# [06:53] <Lachy> unfortunately, so many developers keep copying the Word Processor interface, instead of innovating with something really good
# [06:53] <Zeros> What about bugs in Firefox and Safari's float model or the hasLayout ones in IE that cause really odd bugs like missing blocks, text content, images, extra spaces...
# [06:53] <Lachy> Zeros: I gave a brief overview of how an editor should work either in this channel or #whatwg a week or two ago, check the logs
# [06:53] <sbuluf> lachy, agreed again.
# [06:54] <mjs> users don't seem to be good at thinking about meaning instead of style
# [06:54] <sbuluf> lachy and i also discussed the topic some a couple of days ago
# [06:54] <Zeros> Lachy, I will; though i don't think its possible to make any type of wysiwyg editor for HTML.
# [06:54] <Lachy> mjs: it depends upon the way you present the choices to the uesr
# [06:54] <Zeros> Not one that generates decent markup and renders consistently anyway.
# [06:55] <sbuluf> one general question: have you seen the url i posted above, in the light of precisely this editability problem?
# [06:55] <Lachy> sbuluf: what UIR?
# [06:55] <mjs> it's possible to make a WYSIWYG editor, just not one that outputs markup that we'd consider as following best practices
# [06:55] <Lachy> *URI
# [06:55] <mjs> (I mean, the latter might be possible too, it's just beyond the current state of the art)
# [06:56] <sbuluf> lachy, http://www.teoriadetodo.com.ar/fips/specs/cdl/anatomy.htm
# [06:56] <sbuluf> particularly, from the url above... "CDL cleanly separates content, from presentation, from structure, from semantics, from behaviour"
# [06:56] <Lachy> one day I'll get around to writing up a descent description of how a good WYSIWYG editor should work
# [06:57] <sbuluf> lachy, please do
# [06:57] <Zeros> Well, if we implemented XHTML2 and an entirely new style language we could get the same thing we'd get from CDL sbuluf. All the implementations would be new.
# [06:57] <Zeros> We'd just have to make the spec so strict that everyone's implementation would be the same, hah.
# [06:58] <sbuluf> zeros, exactly
# [06:58] <Lachy> the interface would need to be task oriented, rather than presentation oriented
# [06:58] <sbuluf> unfortunately, i don�t think that is in scope here, which is why yesterday i asked certain questions here. and is also why i think it would probably need to be done separately from w3c
# [06:59] <sbuluf> http://www.teoriadetodo.com.ar/fips/ <--zeros
# [07:00] <mjs> xhtml2 and CDL would both be out of scope for this group
# [07:00] <mjs> xhtml2 isn't out of scope for the xhtml2 WG
# [07:00] <sbuluf> mjs, see now why i asked all those questions yesterday?
# [07:00] <Zeros> sbuluf, I can't find it right now, but there's a document about how to write a good spec, and one of the main points is "The reference implementation should not be the only possible implementation"
# [07:01] <Zeros> Not that I think that's possible with HTML anyway since it needs to render on so many different types of UAs
# [07:01] <mjs> sbuluf: you could have asked more directly
# [07:02] <sbuluf> mjs, well, you might note that i was not quite asking, in fact. i was just suggesting that part or either the charter or your design goals list could, and probably should, be more explicit about the whole wg scope
# [07:03] <sbuluf> mjs, if you noticed, i did not think, at all, that any CDL related stuff would be within scope. pretty much the opposite.
# [07:03] <sbuluf> i just mentioned it today, cause it seemed relevant to a topic at hand, perhaps some ideas could help
# [07:07] * Joins: icaaq (icaaaq@85.228.55.162)
# [07:16] <sbuluf> mjs, i just relized, btw, that my own design goals page is not up to date (that's a very old version). would yopu like me to upload a more up to date one, just in case anything might be of use for yours?
# [07:17] <mjs> sbuluf: depends - what project are your design goals for?
# [07:17] <sbuluf> mjs, CDL, not same as yours. and many points are even diametrically opposed to wat this wg has in mind. but perhap�s, even then, some might be of use.
# [07:18] <Zeros> CDL is your project?
# [07:18] <sbuluf> barely ideas up to now, zeros. those pages, as you surely noted, are terrible beta
# [07:19] <mjs> I'm mainly interested in things that will be relevant to the design of the next generation of HTML
# [07:19] * Quits: h3h (bfults@70.95.237.98) (Quit: h3h)
# [07:19] * Quits: mjs (mjs@64.81.48.145) (Quit: then we we)
# [07:20] <sbuluf> mm, i'll take that as a "no", i think.
# [07:21] <sbuluf> zeros, i'm behind it, yes, if that's what you meant
# [07:34] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Client exited)
# [07:38] <sbuluf> lachy, do you think you'll wirte about proper wysiwyg (or wymiwyg) editing soon?
# [07:38] <Lachy> no idea, it depends if I have the time, motivation and knowledge to do so
# [07:39] * Joins: heycam (cam@203.214.79.176)
# [07:39] * Joins: Grauw (ask@202.71.92.74)
# [07:39] <sbuluf> lachy, teoriadetodo at gmail is my mail adress, in case you do
# [07:40] <sbuluf> i offer myself to diuscuss the topic further, or to contribute to writing, if you ever decide to go on
# [07:40] <Lachy> send me an e-mail about it
# [07:40] <sbuluf> right.
# [07:41] <Lachy> otherwise, I'm likely to forget
# [07:41] <sbuluf> same happens to me =P
# [07:43] <sbuluf> i reckon it will be important too, curiously. this wg charter includes a line, apparently requiring wysiwyg editing as a feature. but i reckon it might turn out to be just about impossible, with current state of specs
# [07:44] * Joins: mjs (mjs@64.81.48.145)
# [07:47] <Lachy> the wysiwyg editing feature is referring to contentEditable, not to general HTML authoring tools
# [07:49] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [07:49] <sbuluf> the charter says "Editing APIs and user-driven WYSIWYG editing features"
# [07:49] <Zeros> We should create a standard for what contentEditable generates. Its useless if every browser makes something different.
# [07:50] <sbuluf> ithought the API's bit referred to programmatical way, while the WYSIWYG bit referred to end-user authoring tools
# [07:50] <sbuluf> you reckon this is not the cacse, lachy?
# [07:50] <sbuluf> *case
# [07:50] <mjs> that's not the intent
# [07:50] <mjs> contentEditable allows live editing, execCommand is the API
# [07:52] <MikeSmith> mjs - about your earlier question on difference between HTML and PDF as rich hypertext formats ...
# [07:52] <sbuluf> mjs, if that was an answer for me, thanks, i'm not sure i undertand, or know enough, but i'll research some.
# [07:53] <Zeros> execCommand is poorly named
# [07:53] <MikeSmith> I wonder if the distinction of considering PDF to be a "terminal" or "final" rendering format makes sense
# [07:53] <MikeSmith> and also the distinction that PDF is intended to be a user-unalterable presentation of the page layout as the author intended it
# [07:55] <MikeSmith> while browsers and other UAs allow end users the choice to display HTML in alternate presentational views
# [07:55] <MikeSmith> for example, by selecting their own CSS stylesheet instead of using the author's CSS
# [07:55] <MikeSmith> or supplementing the author's CSS
# [07:58] <mjs> I users selecting their own stylesheet really the main thing that is different about HTML?
# [07:58] <mjs> because very few users do that
# [07:59] <marcos> MikeSmith: I thought PDF allowed at least some of that flexibility... unlike PostScript which I assume would be fairly close to a final rendering format.
# [07:59] <MikeSmith> mjs - well, perhaps it's not just the fact that users can alter the presentation, but that UAs can also
# [07:59] <MikeSmith> for example, the Small Screen Rendering view in Opera Mobile/Mini
# [08:00] <Zeros> Can you embed remote resources into a PDF?
# [08:00] <MikeSmith> (which as I guess you know puts all content into a single column)
# [08:00] <MikeSmith> Zeros - yes
# [08:00] <Zeros> Hmm, so you can load images on another server.
# [08:00] <MikeSmith> you can embed other (hyperlinked) PDFs within a PDF
# [08:01] <MikeSmith> Zeros - sorry, I missed the word "remote"
# [08:01] <MikeSmith> I don't know about embedding remote resources
# [08:01] <Zeros> I'd say that's a big difference between HTML and PDF
# [08:02] <sbuluf> for, me, the main issue is: "can PDF be considered a good content authoring format?" and given that in practice, i never seem to achieve lossless PDF-to-other-formats lossless conversion, the answer seems to be "no"
# [08:02] <Zeros> You can use dataurls, but they're pretty limited
# [08:02] <Zeros> sbuluf, the same is true of HTML though, so what do you gain using one over the other?
# [08:03] <Zeros> That was the issue that mjs was presenting I think
# [08:03] <marcos> The level of abstraction of Pdf is too close to the final form.
# [08:03] <MikeSmith> marcos - I know PDF allow some flexibility, but I would argue that a large part of their distinctive value is that they don't let users or PDF UAs (Acrobat Reader, xpdf, whatever) alter the basic page layout
# [08:04] <MikeSmith> part of the value of having a PDF is that I say say to you, look at the second paragraph down on page 12
# [08:04] <sbuluf> sbuluf, it might be true about HTML, perhaps (i dunno, some seem to think properly coded HTMl might work). but what about once we move into XML-land? doesn't XML, by its strict nature, or some other factors, achieve a "lossless reprocessability" goal?
# [08:04] <MikeSmith> and know that you'll be looking at the same thing as me
# [08:04] <sbuluf> s/sbuluf/zeros/
# [08:05] <marcos> and I would say look at some.html#identifier and we would be looking at the same thing?
# [08:05] <Zeros> sbuluf, there's no way to convert from XHTML to some random format and back to XHTML without losing something
# [08:05] <marcos> kinda sorta
# [08:05] <Zeros> same with PDF
# [08:05] <mjs> higher level of abstraction might be a good way to think about it but is hard to express clearly and concisely
# [08:05] <MikeSmith> marcos - yeah, true
# [08:06] <mjs> I think most people would agree that elements like <margin> or <textcolor> would be inappropriate for HTML
# [08:06] <marcos> MikeSmith, I can change the print layout of PDF as well so what you say may not always hold
# [08:06] <mjs> is there a way to say why those don't make sense, but <section> or <figure> do?
# [08:07] <sbuluf> zemjs, <section>, or <figure>, are datastructures, while the former are just presentation?
# [08:07] <marcos> because <figure> is more of a common design pattern that can be abstracted?
# [08:07] <marcos> and so is section
# [08:07] <MikeSmith> marcos - I know it doesn't always strictly hold, but I think in common practice it fits the normal use cases for PDFs
# [08:08] <mjs> having margins is also a common design pattern
# [08:08] <sbuluf> mjs, but isn't it presentation, as opposed to a datastructure?
# [08:08] <marcos> but that is presentational
# [08:08] <mjs> I don't know what it means to say some markup is a data structure and other markup isn't
# [08:08] <Hixie> mjs: that's just media independence
# [08:08] <marcos> content, structure and style are the separations of concerns
# [08:08] <MikeSmith> mjs - saying that HTML has a higher level of abstraction seems to me like a relatively clear and understandable way to describe it
# [08:09] <mjs> MikeSmith: but that doesn't clarify how to express the right level of abstraction
# [08:09] <sbuluf> mjs, by datastructure i mean, roughly, a bunch of )optionally ordered) data fields (namely, label/value pairs
# [08:09] <mjs> perhaps media independence and ability to alter presentation without changing the content (what I called Separation of Concerns) are really the main points to capture
# [08:10] <marcos> the right level of abstraction might be based on usage patterns in the wild.
# [08:10] <sbuluf> mjs, examples of datastructures in documents: a list, a table, a paragraph (the simplest one), etc
# [08:10] <marcos> All english speakers might agree that we don't need to mark up things at the level of <word> or <character>
# [08:10] <marcos> but is ok
# [08:11] <mjs> sbuluf: so out of or or <textcolor>, which would you consider a data structure?
# [08:11] <Zeros> mjs, A figure is a fundamental unit of a document. It defines a region of the document and its meaning. <margin> isn't defining a region of the document, but rather how to display another region that has a meaning beyond just the visual presentation.
# [08:11] <marcos> sorry, I missed the definition of "data structure" in this context ?
# [08:12] <sbuluf> mjs, i consider things like or a lishgtly different problem, cause while they *do* enclose content, and *can* be seen as a label/pair value, they are inline, while usually datastructures are bloicks, chunks. is this useful?
# [08:13] <sbuluf> marcos: mjs, by datastructure i mean, roughly, a bunch of )optionally ordered) data fields (namely, label/value pairs
# [08:13] <Zeros> sbuluf, your own statement shows its useful
# [08:13] <Zeros> "and *can* be seen"
# [08:13] <mjs> I'm not sure "data structure" clarifies anything
# [08:13] <Zeros> the emphasis you added with *'s
# [08:14] <MikeSmith> mjs - I think as far as writing a description goes, having some concrete illustrative examples included along with the description would help; e.g., "Having a document source in HTML form allows a user or UA to do X -- easily -- while having it in PDF (or whatever) form does not."
# [08:14] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [08:14] <Zeros> Without and that's not possible unless we make something up sbuluf
# [08:14] <marcos> yeah, data structure makes little sense to *me* in this context
# [08:15] <sbuluf> datastructures are, roughyl, any instance of what is commonly referred to as "structured content". i.e, anything you might want to plug in databases, normally
# [08:15] <Zeros> What about construct?
# [08:15] <mjs> and and a hypothetical inline <textcolor> element would all have the exact same logical relationship to their contained text
# [08:15] <Zeros> as in "language construct"
# [08:15] <mjs> I don't think HTML elements map very well to language constructus
# [08:15] <Zeros> mjs, only to a visual UA
# [08:15] <mjs> most of them are above the level of language
# [08:16] <marcos> you mean the DOM?
# [08:16] <mjs> Zeros: what I mean is they tag a sequence of characters with a label
# [08:16] <Zeros> mjs, oh okay, then yes, they're the same.
# [08:16] <mjs> that is just as much a "data structure" or not, regardless of what the label is
# [08:17] <Zeros> yeah, I see what you're saying. Data structure seems like a bad term then?
# [08:17] <mjs> I think this might be too abstract to result in a useful design principle
# [08:17] <marcos> I can understand the DOM as a data structure.
# [08:17] * marcos obviously lost
# [08:18] <sbuluf> mjs, ultimately yes, content inside tags are a datastructure as well, strictly speaking. i only pointed that they are *perceived* as slightly different because of the same reasons people tend to distinguish block and inline levels in HTML
# [08:18] <Zeros> mjs, What about stating that the goal is to not introduce elements whos meaning is tied to a specific UA type and have no abstract meaning that can be mapped to a different context?
# [08:18] <Grauw> a data structure is just a structure of data, of any kind, period
# [08:18] <sbuluf> graw, yes
# [08:18] <Grauw> I've had a course on it at university :)
# [08:18] <Zeros> mjs, <textcolor> is very specific to a type of UA so it'd violate that principal
# [08:18] <MikeSmith> perhaps "logical unit" might be more clear than "data structure"
# [08:18] <marcos> Grauw, got it :)
# [08:19] * Joins: gavin (gavin@74.103.208.221)
# [08:19] <sbuluf> MikeSmith, datastructure itself is just a term. it comes more from the programmer's lexicon, i think
# [08:19] <mjs> Zeros: seems like it would apply to a lot of different types of UAs - desktop, handheld, print, slideshow, various kinds of editors, search engines that want to find attempts to make text invisible...
# [08:19] <MikeSmith> sbuluf - I realize that
# [08:20] <Grauw> e.g. a red-black tree http://en.wikipedia.org/wiki/Red_black_tree is a way to structure data
# [08:22] * Joins: loic (loic@90.29.252.98)
# [08:22] <Zeros> mjs, Okay, I see what you mean. The only thing I can think of is that we shouldn't introduce something better expressed with CSS. Changing stylesheets shouldn't change the meaning of the document, but changing the html should?
# [08:22] <Zeros> this principal does seem hard to define
# [08:23] <Grauw> isn't the term ‘semantic markup’ covering that idea?
# [08:24] <sbuluf> it is, imho. is the reason why was proposed instead of , so you can render content not just to visual UA's, but also to say, a speech sunthesizer
# [08:25] <sbuluf> i.e, you *can* aplly emphasis to voice, but not "italics"
# [08:26] <mjs> I think many people consider a failed experiment
# [08:26] <mjs> that's part of the reason people don't like the term 'semantic markup'
# [08:27] <Grauw> well let them get back to their font tags then, if they want that so badly :)
# [08:27] <Grauw> I mean, if you do not express semantics, then there's no point in having CSS
# [08:27] <Grauw> if you use for italics, there’s no real reason why you should have font-style: italics
# [08:29] <Hixie> doesn't mean "italics" in the whatwg html5 draft :-)
# [08:29] <sbuluf> imho, the point was not some academic, nitpicking, ivory tower capprice. i think, instead, that it provided the above mentioned functionality/coherence. one can not stand in front of an actor and say to him "ok, now please italize this part of the script". but one can say "please emphasize this part".
# [08:29] <Grauw> one who uses on the other hand can on a whim decide to render all emphasis with bold or larger or underline or in a different colour, although that may not exactly match with common typographical convention (bold and underline are used as such though), the advantage is clear
# [08:29] <marcos> I was just going to say, depends on your definition of italics...
# [08:30] <Grauw> styling an italics tag to be bold would be kind of weird :)
# [08:30] <Zeros> Hixie, I think that's a mistake since it takes all the presentational abuses of and makes them into semantic markup
# [08:30] <marcos> Exacly what I was saying before, its all based on usage patterns in the wild.
# [08:30] <Hixie> Zeros: as opposed to the presentational abuses of <blockquote> that we're making into semantic markup?
# [08:30] <sbuluf> if means emphasis, then i think is more coherent to call it
# [08:30] <Hixie> wait, why is making things right a bad thing?
# [08:31] <Hixie> doesn't mean emphasis
# [08:31] <Hixie> is for emphasis
# [08:31] <Zeros> and you're saying with HTML5 they both mean emphasis?
# [08:31] <Grauw> I don't think the new definition of is improving so much
# [08:31] <Hixie> Zeros: no
# [08:31] <Hixie> Zeros: see the spec
# [08:31] <sbuluf> what does mean in html5?
# [08:31] <Hixie> Zeros: http://www.whatwg.org/specs/web-apps/current-work/#the-i
# [08:31] <mjs> is for things that are not emphasis but would normally be rendered in italics in print
# [08:32] <Grauw> there's a lot of overlap, and the definition isn't exactly clear, it could cover a lot
# [08:32] <Grauw> Example from the spec; The block-level elements are defined above. would rather be <dfn></dfn> instead of
# [08:32] <Zeros> mjs, that should probably be handled in the stylesheet though, not the markup
# [08:32] <Zeros> the print conventions may change depending on who is printing
# [08:32] <Zeros> Hixie, it'd honestly make more sense to deprecate it.
# [08:33] <Hixie> Grauw: <dfn> means it's the defining instance, not just a random use of them
# [08:33] <Zeros> We don't have to remove it, but it can be discouraged. Otherwise we might as well add <center> back in for things normally printed in center?
# [08:33] <Hixie> Zeros: i disagree
# [08:33] <marcos> argh... loading the HTML 5 spec makes my machine sooo slow...
# [08:33] <Grauw> I agree, although there is a need for a means to indicate foreign terms
# [08:33] <Hixie> has uses
# [08:33] <Zeros> Hixie, so does <center>
# [08:33] <Grauw> like felis silvestris catus and je ne sais quoi in the examples of the spec
# [08:34] <Hixie> Zeros: <center> makes no sense in aural media. does.
# [08:34] <Grauw> and I'd say the dream sequence example needs <q>
# [08:34] <mjs> je ne sais quoi makes more sense to me than je ne sais quoi
# [08:34] <Zeros> Hixie, How does giving not break the web? All the abuses of now have special meaning when previously they did not.
# [08:34] <Grauw> (or well, maybe not)
# [08:35] <sbuluf> <mjs> is for things that are not emphasis but would normally be rendered in italics in print <--how does this make sense in aural media?
# [08:35] <Grauw> mjs, how exactly did I say there was *not* a need for an element for foreign phrases, so span with a class would be needed?
# [08:35] <Hixie> Zeros: doesn't really break anything. it changes the meaning of old documents from being meaningless to being confused, but in practice that will have very little effect.
# [08:36] <Hixie> anyway, afk
# [08:36] <Grauw> I was saying the exact opposite, I just think maybe it should not be placed on where it shares semantics with a lot of other things
# [08:36] <mjs> sbuluf: well, how would a reader application render italics in a book? probably by using a distinguished voice
# [08:36] <marcos> I really like the HTML5 def, it captures really nicely: "The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized."
# [08:37] <Grauw> from the description of I think you can divide that up into two categories: different mood, and foreign terms
# [08:37] <Zeros> Making old documents confused hardly seems like no effect.
# [08:37] <mjs> sbuluf: this is what TV Raman, who actually uses a screen reader regularly, recommends as aural presentation for
# [08:37] <Grauw> if you would separate those two out into two elements would be better
# [08:37] <Zeros> We're retroactively redefining what an element that already exists means
# [08:37] <Grauw> and preferably not call them because that would add meaning to existing web sites where none was intended
# [08:37] <Zeros> exactly
# [08:37] <sbuluf> mjs, perhaps he says so because the existence of was there to begin with, and he could not change it?
# [08:37] <Grauw> which is just as bad as inferring sectioning from heading elements :)
# [08:38] <Zeros> Leave them presentational and use something else that has no retroactive effect on existing documents.
# [08:38] <mjs> I think you'll find that definition of captures most actual uses, other ones that should really be but are generated by a WYSIWYG editor that doesn't know any better
# [08:38] <Grauw> example from : The frobonitor and barbinator components are fried.
# [08:39] <Grauw> those are either <dfn> definitions or foreign terms
# [08:39] <mjs> for example none of the italics on this page are emphasis: http://en.wikipedia.org/wiki/HMS_Ark_Royal
# [08:39] <Grauw> so can be used for the same things can be used for?
# [08:39] <sbuluf> mjs, i'm all for wyMiwyg editors, if possible, if that helps. with EM button, instead of I button.
# [08:40] <mjs> sbuluf: then you will get people writing je ne sais quoi
# [08:40] <mjs> which is clearly wrong
# [08:40] <mjs> but people do it because they have been trained that is evil and is good
# [08:40] <sbuluf> mjs, we could create another tag for foreing languages, couldn't we?
# [08:40] <Grauw> not if you add a <foreign-term> element
# [08:41] <Grauw> then people can choose between em and foreign-term, and will choose the one appropriate
# [08:41] <marcos> IMHO, I think the "whose typical typographic presentation is italicized" part is key here.
# [08:41] <mjs> and elements for <ship>, <note>, <species>, etc?
# [08:41] <Grauw> the reason why people overload is because there are cases where is not appropriate
# [08:41] <mjs> with a different button in your editor for each?
# [08:41] <Zeros> I'm going to refrain from getting too heated into this without doing more research into it. :)
# [08:41] <sbuluf> which in turn would normally lead me to an explanation of why i included certain principles in CDL, but unfortunately, that seems to be out of scope here
# [08:42] <Grauw> foreign-term would cover species, I do not claim I made up the best name for such an element in the 10 seconds that it took me to type that phrase :)
# [08:42] <Grauw> as well as ships
# [08:42] <Grauw> maybe just ‘term’ alone would be better
# [08:42] * Grauw nods, yes, a ‘term’ element would be really nice
# [08:43] <sbuluf> mjs, one of the biggest HTML flaws, imho, is that, precisely, it does not allow for inswertion of arbitrary datastructures. just p, ul, ol, table, and a couple more. but why not, instead, an extensibility mechanism, so that we could insert any, at all?
# [08:43] <mjs> a scientific name for a species is not a foreign term
# [08:43] <Grauw> where <dfn> is used for the defining instance of a term
# [08:43] <mjs> it is a scientific term
# [08:43] <mjs> sbuluf: that's called "class"
# [08:43] <Grauw> mjs: as I said, quote "I do not claim I made up the best name for such an element in the 10 seconds that it took me to type that phrase"
# [08:43] <Grauw> quote: "maybe just ‘term’ alone would be better"
# [08:44] <mjs> great, so if you think about what 'term' would apply to, it's pretty much the same set of things as the HTML5 'i'
# [08:44] <Grauw> yes, but
# [08:44] <Grauw> HTML5 also applies to indicate mood
# [08:44] <sbuluf> graw, this might )or might not) interest you: http://www.teoriadetodo.com.ar/fips/specs/cdl/anatomy.htm (is *very* beta, mind you)
# [08:44] <Grauw> which is a different thing
# [08:44] <mjs> so it makes life easier to call it 'i' and Pave The Cowpaths instead of Reinventing The Wheel
# [08:45] <Grauw> as I wrote above, in my opinion you need to separate those two out, or it would be better to use
# [08:45] <Grauw> well, not need, and maybe span would be worse. But anyway, they should imo be separated out.
# [08:45] <marcos> I guess the choice is yours, grauw.
# [08:46] <mjs> two ways to italicize text is already plenty, I'm not sure three are justified
# [08:46] <sbuluf> mjs, "class" was the closest available thing, yes. if you remember my CDL model, you'll notice that i kept it and mentioned it, for the same reason: a generic extensibility mechanism, for unforeseen uses. BUT, i also used "meaning", "structure", "behaviour", etc, for already known uses.
# [08:46] <Grauw> what, italicise? don't think in terms of that.
# [08:46] <Grauw> marcos, I don’t exactly know what you mean
# [08:46] <mjs> I didn't really read your CDL model, sorry
# [08:46] <sbuluf> mjs, k
# [08:47] <Hixie> fwiw, html5 had a <term> element for a while. we removed it, though i forget why. it's probably in the subversion logs or the mailing list.
# [08:47] <marcos> Grauw, you can use either , , ... why add another?
# [08:47] <marcos> oh, and dfn
# [08:48] <Grauw> dfn is the defining instance of a term
# [08:48] <Grauw> what you see is that people want to use (and italicise) terms without defining them
# [08:48] <marcos> yeah, still italics
# [08:48] <Zeros> marcos, you're thinking in terms of presentation not meaning
# [08:48] <Grauw> zeros, indeed
# [08:48] <marcos> No, I'm not. Trust me.
# [08:48] <Zeros> you could use and make it italic if you wanted in the same way you used the span
# [08:49] <Grauw> so <term> would be the ideal accompaniment for <dfn>
# [08:49] <sbuluf> if we include <term>, we might as well include <haiku>, <sonet>, <employee>, <car>, and uncountable datastrucres more as well. this is why i think HTML is flawed, and a good content authoring language should allow for external definition and insertion of arbitrary datastructures.
# [08:49] <Hixie> oh it was called <t>. it was dropped in version 456.
# [08:49] <Grauw> Hixie, why?
# [08:49] <Grauw> btw, <term> seems better, more clear, than <t>
# [08:49] <Hixie> it was dropped same time we added and , presumably for the same reason sbuluf just gave
# [08:50] <Hixie> but if you look in the archives there'll be an e-mail from me explaining the reasoning
# [08:50] <Grauw> I'll never be able to find it, so I won't bother
# [08:51] <Zeros> I don't know if we need term, but we definitely think we need a grouping element for term/definition sets in <dl>
# [08:51] <Hixie> r456 was at 2006-12-22 01:07:05
# [08:51] <sbuluf> hixie, as mere curiosity, and *out* of scope, of this wg, most likely, you might be interested in having a look at this: http://www.teoriadetodo.com.ar/fips/specs/cdl/anatomy.htm (feel free to disregard if not)
# [08:51] <Zeros> I definitely think*
# [08:51] <Hixie> sbuluf: what is it?
# [08:52] <sbuluf> hixie, a very beta p�roject of mine, a language to replace html, plus a lot of other things
# [08:52] <Hixie> aah
# [08:52] <Hixie> good luck replacing html :-
# [08:52] <Hixie> :-) even
# [08:52] <Zeros> like well, RDF?
# [08:52] <sbuluf> thanks =P
# [08:53] <sbuluf> zeros, rdf, or something similar, would be used to externally define what you see in that page as "meaning" in each <section>
# [08:53] <Hixie> sbuluf: might be useful to have a section explaining the design goals and basic principles behind the spec
# [08:54] <sbuluf> hixie, i have one, but apparently forgot to upload it the last time. thanks, and right
# [08:55] <Zeros> sbuluf, RDF is abstract enough it could describe the entire thing and replace it.
# [08:55] <sbuluf> hixie, mind you, the design goals are almost diametrically opposed to the ones being considered here, though, since the idea is to search for an optimal language, not to keep back compat. i.e, from scratch
# [08:55] <Hixie> hehe
# [08:55] <Grauw> RDF doesn't try to replace HTML
# [08:55] <Hixie> man, designing a new language would be so much more fun than doing html5
# [08:55] <Grauw> if that's what you think then you're missing the point ;p
# [08:56] <sbuluf> zeros, yes, i know, and i do not quite discard it, even, the problem is that some people find it difficult, and that is a big problem wrt the learning curve, and even people's very conceptualization
# [08:56] <sbuluf> hixie...let's do it, even for fun, as hobbie =P
# [08:56] <sbuluf> hixie, i don't envy you having to keep back compat here
# [08:56] <Hixie> hah, my full time job is writing a spec, not gonna make it my hobby too :-P
# [08:57] <sbuluf> hixie =P
# [08:57] <Zeros> Grauw, Not at all. But using RDF and a few extensions like DC and you could get to a point where it could
# [08:57] <mjs> TrainML!
# [08:57] * MikeSmith is looking for the spec he wrote that replaces HTML markup with S-expressions, which is what Web documents should have used from the beginning. Just as we all should be programming in lisp if we really knew what we were doing.
# [08:57] * Joins: cwahlers (Miranda@201.68.59.218)
# [08:57] <MikeSmith> I'll post the URL later
# [08:57] <MikeSmith> remind me if I forget
# [08:57] <sbuluf> MikeSmith, pelase do, i'd like to have a look
# [08:58] <mjs> preferrability of sexps vs sgml-ish syntax depends on density of tags relative to text content
# [08:59] <Grauw> Zeros, I don't think RDF, which is merely a format for data, could replace prose
# [08:59] <Grauw> RDF is nothing else than a database system
# [08:59] * MikeSmith warns that stuff he says is not always to be taken seriously
# [08:59] <Grauw> No different than describing an HTML document in a MySQL relational database and then generate an HTML document from it
# [08:59] <Grauw> which is done on many, many websites of course.
# [08:59] * marcos is shocked by the idea that someone does not like RDF!
# [09:00] <sbuluf> zeros, graw, i tend to see it as graw does. altough i sense what zeros mean. i thinklearning curves are very important, though, and that some html-like language is basically better to write content on cause of that, looks simpler
# [09:01] <Grauw> Youtube is for a large part HTML generated from a database, which is probably some relational thing but could be RDF as well, which would give it a number of benefits
# [09:01] <Zeros> Grauw, reference plain text documents and start defining the relationships and meaning with RDF, or add some extensions as its XML after all and then you've replaced HTML
# [09:01] <sbuluf> MikeSmith, oh i see, i did not know what s-expressions meant. i assume, if joke, that you meant string theory stuff.
# [09:02] <MikeSmith> sbuluf - I have a spec for that too
# [09:02] <Grauw> zeros: as I said, it's not anything new that RDF introduces, it is done on tons of websites using conventional databases already
# [09:02] <MikeSmith> Grand Unification Markup, I call it
# [09:02] <MikeSmith> GUM
# [09:02] <sbuluf> MikeSmith =PP
# [09:02] <Zeros> Grauw, how does that change that it could be used to replace HTML with some abstract extensions?
# [09:03] <sbuluf> zeros, how would you do it? and how would it affect learning curve?
# [09:03] <Grauw> I don't think it can replace entirely... if you look at a database, if there's blurbs of text they're usually contained in a single cell
# [09:03] * MikeSmith is also reminded that he meant to propose we change the list culture to discourage "+1" message and instead encourage people to use "pirate talk" to express agreement
# [09:03] <MikeSmith> as in "Aye, matey"
# [09:03] <Zeros> That's too conventional, you'd just need to break it up more Grauw like in a HTML document
# [09:04] <Zeros> sbuluf, If you replaced HTML with RDF+Stuff you'd end up with a uselessly complex language :)
# [09:05] <Grauw> I'm not saying you couldn't, I mean you can describe HTML pages in XML (another database format, in a sense). RDF is graph-based, so more flexible than XML, and thus it can express the same things.
# [09:05] <Zeros> There is no way RDF can be more flexible than XML since its expressible within XML.
# [09:05] <sbuluf> zeros, so the iudea in that CDL page, in which HTML becomes just <sections>, basically, but each section can externally define structure, presentation, meaning, etc, would be better, simpler?
# [09:06] <Grauw> zeros, XML is in essence a tree-based structure for data, RDF is graph-based
# [09:06] <sbuluf> xml is a tree, while rdf is a graph
# [09:06] <sbuluf> exactly
# [09:06] <Hixie> mjs: i use SVG and XBL1 for my train software (seriously)
# [09:06] <Zeros> If you can express rdf in XML then you can make XML that represents a graph
# [09:06] <Zeros> rdf is not more flexible
# [09:07] <sbuluf> hence, we could represent html in rdf , but we would need to add some ordering information as well...which would turn it into equivalent to a tree
# [09:07] <mjs> Hixie: I think you mentioned that the other day
# [09:07] <mjs> by way of commentary on <use>
# [09:07] <Zeros> Grauw, Anyway, for kicks. What does RDF give me that a conventional SQL database doesn't?
# [09:07] <Grauw> indeed, the ordering is implicit in XML and nonexistant in RDF
# [09:08] <Hixie> mjs: yeah, god, they should drop <use>, seriously
# [09:08] <Grauw> it's a web database format, SQL databases are not
# [09:08] <sbuluf> zeros, you can make automatical mashups. i.e, you can merge graphs with almost no cost, i think
# [09:08] * Hixie wonders what makes something a "web database format" as opposed to some other database format
# [09:08] <Grauw> plus relational databases deal with various graph structures in a very very awkward manner
# [09:08] <sbuluf> to merge xml is not trivial, to make graphs is, afaik
# [09:09] <sbuluf> s/make/merge/
# [09:09] <mjs> Hixie: sadly they have their own compat issues now
# [09:09] <mjs> but <use> is eyebleedingly insane
# [09:09] <Zeros> Grauw, What do you plan to query the RDF database with?
# [09:10] <Grauw> RDF is based on URLs (which can be dereferenced too) so that data can be combined from various sources
# [09:10] <sbuluf> hixie, i think he meant that xml is suitable to send over the wire
# [09:10] <Grauw> *URIs
# [09:10] <Grauw> (which can not always be dereferenced)
# [09:10] <sbuluf> hixie, as a light interchange format
# [09:10] <Hixie> sbuluf: ah
# [09:10] <Grauw> zeros, SPARQL?
# [09:10] <Hixie> sbuluf: well then conventional databases are also "web database formats", they just use CSV as their interchange format
# [09:11] <Grauw> or HTTP REST requests
# [09:11] <sbuluf> hixie, very much, true
# [09:11] <Grauw> Hixie, you can't just merge arbitrary CSV files
# [09:11] <Grauw> and have their primary keys link together
# [09:11] <Hixie> you can't just merge arbitrary rdf graphs either, if they don't have vocabularies in common
# [09:11] <Grauw> in fact, merging would be a very complicated process, due to the table-structures
# [09:12] <sbuluf> graw, neither xml, i think, but yes rdf?
# [09:12] <Grauw> you can, if the URL is the same, even if you don't know the vocabulary, they reference the same thing
# [09:12] <Hixie> talking about "xml" and "rdf" is like talking about "ink-and-paper" and "english"
# [09:12] * Parts: icaaq (icaaaq@85.228.55.162)
# [09:12] <Hixie> they're different classes of things
# [09:12] <Grauw> sbuluf, it would also be difficult for XML, yes
# [09:13] <Grauw> Hixie, no, English would be like ontologies
# [09:13] <Zeros> Grauw, I don't see any advantage in that over a conventional database. I do some nasty performance hits though.
# [09:13] <sbuluf> hixie points to the problem of rdf mappings, which i do think is a problem
# [09:13] <Grauw> RDF is ink-and-paper, RDFS and OWL are English grammar
# [09:13] <sbuluf> (of vocab mappings, perhaps, better)
# [09:13] * Hixie steps out of the conversation since he really doesn't care to talk about RDF right now
# [09:14] * mjs straps on his abstraction space suit
# [09:14] <Grauw> Zeros, then don't use RDF but a conventional database
# [09:16] * MikeSmith wonders how much any of this discussion has actually helped mjs with the problem he was trying to solve
# [09:16] <Grauw> quote "RDFS and OWL are English grammar" - sorry, I meant to say RDFS and OWL are a grammar to describe language structures (they could contain a description of English grammar)
# [09:17] <mjs> MikeSmith: it made me feel satisfied with Media Independence and Separation Of Concerns as expressing the important points that aren't too abstract to be useful
# [09:18] <sbuluf> the discussion will go on
# [09:19] * Joins: edas (edaspet@88.191.34.123)
# [09:20] <sbuluf> graw, for curiosity..did you see that url of mine?
# [09:21] <Grauw> I briefly looked over it
# [09:22] <sbuluf> i see, thanks.
# [09:24] <Grauw> I don't really see the benefit, I think HTML does the job pretty well, although it misses markup for certain things that are fairly common in documents.
# [09:25] <Grauw> turning everything into attributes instead of elements (basically what I see is span and div with a class attribute on it with certain predefined meanings) isn't really the answe
# [09:25] <Grauw> r
# [09:26] <Grauw> I mean, you have block or inline as top level elements (section and in elements), but you could just as well put those in a class element as well, I do not see why they are so special that they're first-class citizens
# [09:27] * Quits: Lachy (chatzilla@220.245.91.147) (Quit: Chatzilla 0.9.77 [Firefox 2.0.0.3/2007030919])
# [09:27] <sbuluf> html does not allow for extarnal definition plus insertion of arbitrary datastructures. also, this separates not just content from presentation, but also from structure, meaning and behaviour, which i think is a very simple idea to grasp, and hence reduces learning curves for newbies.
# [09:27] <Grauw> in the end however <e c="in e l"> to say ‘this is an inline element that's emphasised and a link’ isn't really author-friendly. Plus it'll be hell to define a schema for it.
# [09:27] <sbuluf> (the rest of the ideas being mostly secondary)
# [09:28] <sbuluf> this also mighe facilitate wymiwyg editing
# [09:28] <Grauw> sbuluf: I don't see the problem in HTML that it solves, and because it's entirely new there's no familiarity with the format, no implementations, etc
# [09:29] <Grauw> and, how is it different from XML?
# [09:29] <Zeros> sbuluf, the XML serialization of HTML allows arbitrary data structures.
# [09:30] <sbuluf> xml is bigger, this is more restricted. same reason why xhtml exist, as opposed to full xml
# [09:30] <sbuluf> zeros, it does?
# [09:30] <Grauw> restricted how?
# [09:30] <sbuluf> restricted to just a few possible elements, mostly sections, as pure containers
# [09:30] <Zeros> sbuluf, Certainly. You can mix namespaces in your XHTML document to add arbitrary data like DC or RSS inline
# [09:31] <sbuluf> zeros, you mean in html5? of in the former xhtml?
# [09:32] <Zeros> You'd just need to style it with CSS, and hope the UA implemented proper styling of arbitrary XML
# [09:32] <Zeros> sbuluf, HTML5 is not XML, though they want to provide an XML reformulation of it.
# [09:33] <sbuluf> zeros, so you meant xhtml5, not the former xhtml, right?
# [09:33] <Zeros> both
# [09:33] <sbuluf> thanks
# [09:33] <Zeros> XML by definition lets you mix namespaces to combine data types.
# [09:33] <sbuluf> right, but no so former html
# [09:33] <Zeros> right
# [09:34] <Zeros> Whether its a good idea to allow that kind of mixing is a matter of heated debate. Do we really need random data snippets mixed with HTML?
# [09:34] * Quits: mjs (mjs@64.81.48.145) (Quit: then we we)
# [09:35] <Grauw> So this allows you to define block and inline content: HTML does the same. This allows you to add arbitrary meaning: class does the same, and RDFa with an ontology does it more formally. This allows you to mix data with content: XHTML is an XML language and thus you get the benefit of namespaces
# [09:35] <Grauw> zeros: I think not :)
# [09:35] <sbuluf> re styling of arbitrary xml...well, a default possibility is that xml is ultimately always just a bunch of [ordered] label/values pairs, hence, it can always be default-styled as just that, unless the author can specify a custom style for that datastructure
# [09:36] <sbuluf> random data snippets?
# [09:37] <sbuluf> graw, you mean you do not see differences with what is currently being done here?
# [09:38] <Grauw> not just here
# [09:38] <Zeros> Grauw, I see a real advantage to MathML or SVG embedding, the problem is that XML doesn't limit you to /just/ those formats. So people can make up random stuff too.
# [09:38] <Grauw> but yeah
# [09:38] <Grauw> zeros: I agree
# [09:38] <sbuluf> zeros, why would that be a problem, though?
# [09:39] <Grauw> then again, random stuff isn't any less suited to be inserted in XHTML than MathML or SVG really... the definitions of the meaning of the tags are just less public.
# [09:39] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
# [09:40] * Joins: anne (annevk@81.68.67.12)
# [09:41] * Joins: icaaq (icaaaq@85.228.55.162)
# [09:41] <Grauw> anne, you'll love this: http://leobard.twoday.net/stories/3520709/
# [09:41] <Grauw> and I'm referring to the markup
# [09:41] <Grauw> of that link
# [09:42] <sbuluf> graw, did you think css, and the separation of content from presentation, plus to have a way to externally deal with presentation, was a good idea? if so doens't this, which extends the same principle to structures, etc, looks better in a similar way?
# [09:43] <Grauw> yes, that's what XML or RDF is for...
# [09:43] <Grauw> you can serialise them to HTML, or in case of XML, style it
# [09:44] <Grauw> s/serialise/transform
# [09:44] <Grauw> XML has better tools support for both (XSLT for transforming and CSS for styling)
# [09:44] <sbuluf> right, and this is not too far from full xml, only more restricted to the needed elements (mostly <section>, as pure nestable containers)
# [09:44] <Grauw> (I wish there was an XSLT for RDF... XUL has some, but it's not ideal)
# [09:45] <Grauw> I don't understand why you would need some kind of section or inline containers?
# [09:47] <sbuluf> graw, you reckon full xml would be better, directly, as a general content authoring language?
# [09:47] <Grauw> For prose documents, XHTML is better. For data, XML is better.
# [09:47] <Grauw> (or RDF)
# [09:49] <sbuluf> graw, why did you mention xhtml, instead of full direct xml? and does that same thing explain why i'd rather use cdl instead of full xml?
# [09:50] <sbuluf> if, so, how would you describe that reason?
# [09:50] <Grauw> Because XML does not have any semantics attached to it. XHTML does.
# [09:51] <Grauw> and I don't understand the other question :)
# [09:51] <sbuluf> lemme think a bit =P
# [09:52] <Grauw> When I say for data, RDF or XML is better, I mean to say of course preferrably one which has a specification or ontology which makes it meaningful, as opposed to your own madde-up format.
# [09:53] <sbuluf> i think first and foremost, you mean for authoring structured content. am i right?
# [09:53] <Grauw> e.g. iCal for calendar data (exists in both RDF and XML), SVG (XML) for graphics, MathML (XML) for formulae, FOAF (RDF) for person information, etcetera.
# [09:54] <Grauw> Along these lines, for prose XHTML is the XML format of choice.
# [09:55] <sbuluf> and does this very same reason for picking xhtml, and not full xml, answer you former question about why cdl, instead of full xml?
# [09:55] <Grauw> and XHTML can also be used as a final-form output medium for various human-oriented serialisations of these data formats.
# [09:55] <Grauw> sbuluf: except it seems to me that you are creating something new with no obvious benefits over existing technologies...
# [09:56] <sbuluf> graw, i see, let me see if i can explain my perceived advantages
# [09:56] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
# [09:56] <Grauw> (it's ‘grauw’, btw, with a u in it :))
# [09:56] <Zeros> There's an XML parsing library for just about every language
# [09:57] <sbuluf> oops, sorry!
# [09:57] <Zeros> I think that's a huge advantage over making up you own format for the data
# [09:58] <Zeros> which of course could be XML itself and then why not use XHTML since it already has some support?
# [09:58] <sbuluf> cdl would be xml itself, just a small subset, mostly just <section>. very much like if you coded webpages today just using <div> and
# [09:59] <sbuluf> imho, the problem with xhtml, is that it hardwires some datastructures into the language
# [09:59] <Zeros> Wouldn't that be hugely bloated since you'd have to define the meaning of everything?
# [09:59] * anne isn't sure what there's to like about that page
# [09:59] <sbuluf> examples of datastructures: ol, ul, table, p
# [10:00] <Zeros> 61 errors, xml prolog, xhtml transitional
# [10:00] <sbuluf> but not, for example, employee, car, haiku, and infinite more possibilities
# [10:00] <Zeros> its the poster child for XHTML usage
# [10:00] <Zeros> kind of sad
# [10:01] <sbuluf> what i propose is exqctly the opposite: nothing (no datastructure) predefined. instead, just a mechanism to define any arbitrary datastructure externally, in some schema language
# [10:02] <Zeros> sbuluf, that'd render screen readers and semantic data extractors (ex. search engines) useless
# [10:02] <sbuluf> izeros, why so?
# [10:02] <Zeros> The data on every site could be in a radically different structure because everyone can use their own description of what it's supposed to mean
# [10:03] <sbuluf> is that different than creating some datastructure today in xml or rdf?
# [10:04] <Zeros> No, but its very different than using XHTML which has defined meaning attached already.
# [10:04] <sbuluf> and are those "meanings useful? and in fact, are they really "meanings"? or are *datastructures, instead?
# [10:05] <sbuluf> for example, do you any time ask google to list all paragraphs in the net?
# [10:05] <sbuluf> or all tables?
# [10:05] <sbuluf> do you use those structures for searching, at all?
# [10:05] <Zeros> Of course they're useful
# [10:05] <Grauw> anne, in the context of your thought that xml-well-formedness checking is fairly worthless
# [10:05] <Grauw> this is a nice example of where it indeed is quite worthless
# [10:06] <Zeros> how else do you think google figures out what's a heading and what's a paragraph and what is relevant sbuluf? How do you think a screen reader knows how to read a documenet?
# [10:06] <Zeros> document
# [10:07] <Zeros> Grauw, Its not worthless, that document isn't being sent as xml at all. Its malformed HTML.
# [10:07] <Grauw> well-formed, in case of HTML5
# [10:07] <Zeros> That document is well formed HTML5?
# [10:07] <sbuluf> zeros does google really figures what is a heading, and what is a paragraph? what would google do with that? is it of any use, search-wise?
# [10:08] <Grauw> from what I gather, XHTML appendix C constructs are now conformant according to HTML5
# [10:08] <Grauw> but anyway, the point is, had it been sent as XML, it would not have helped the broken markup
# [10:08] <anne> almost all XHTML documents served as text/html are like that, btw
# [10:09] <sbuluf> zeros, do we agree, first, that things like ol, ul, etc, are structures, more than meanings?
# [10:09] <Grauw> although this does seem like a case where some mechanism has tried to automatically fix up errors in non-well-formed XML
# [10:10] <Zeros> Grauw, It would have helped because the markup would have bombed entirely as its invalid, in which case the author would be compelled to fix it.
# [10:10] <Grauw> Zeros, for the record I agree completely with you :)
# [10:10] <Zeros> And can we even allow Appendix C constructs and still be valid SGML?
# [10:11] <Grauw> Zeros: never mention SGML again in relation to HTML :)
# [10:11] <Zeros> /> is a NET feature which means something else entirely
# [10:12] <Grauw> HTML is not an SGML language
# [10:12] <Zeros> um, sure it is.
# [10:13] <Zeros> XML is a SGML subset too
# [10:13] <hsivonen> Zeros: as of HTML5, HTML is officially not an SGML language
# [10:13] <Zeros> hsivonen, HTML5 is not a standard, its an adhoc spec that some people put together.
# [10:13] <hsivonen> Zeros: as far as browser implementations go, it has never been
# [10:13] <anne> much like HTML1
# [10:14] <anne> Zeros, HTML5 reflects the web, not some pipedream the HTML2 guys had
# [10:14] <Grauw> Zeros, the W3C HTML WG operates on the same premises, quote from the charter "the Group will not assume that an SGML parser is used for 'classic HTML'"
# [10:14] <Zeros> Citing HTML5 as being the definition of HTML is not correct
# [10:14] <anne> whatever suits you
# [10:14] <Zeros> heh
# [10:14] <Zeros> Well if we take HTML5 as the gospel why have this WG at all?
# [10:14] <anne> patent stuff
# [10:14] <hsivonen> Zeros: some people say it is inappropriate to cite CSS 2.1 as the definition of CSS
# [10:14] <Zeros> Lets just let the WHATWG do it for us
# [10:14] <Zeros> since we have no authority
# [10:15] <anne> we certainly don't have the authority to keep it SGML based
# [10:16] <anne> you can read that in the charter
# [10:16] <Grauw> exactly. it's part of the charter.
# [10:16] <Zeros> the charter mentions classic HTML
# [10:16] <Zeros> it makes no mention that HTML5 is not SGML
# [10:16] <anne> you should read better
# [10:17] <anne> any, this discussion is pretty pointless
# [10:17] <hsivonen> Zeros: that's charterese for "neither SGML nor XML"
# [10:17] <anne> s/any,/anyway,/
# [10:17] <Zeros> You're right it is
# [10:18] * Joins: tylerr (tylerr@24.16.148.66)
# [10:18] <Zeros> And okay, if you define not assuming as not being
# [10:19] <tylerr> Hey folks.
# [10:19] <anne> morning
# [10:19] <sbuluf> hi
# [10:19] <Zeros> hsivonen, abomination?
# [10:19] <anne> Zeros, but you want it to be SGML based?
# [10:19] <tylerr> What do you all think of the <term> element proposal?
# [10:20] <anne> I think <term> should be
# [10:20] <Zeros> anne, not particularly
# [10:20] <anne> and <code xref> etc.
# [10:20] * Parts: icaaq (icaaaq@85.228.55.162)
# [10:20] * Joins: icaaq (icaaaq@85.228.55.162)
# [10:20] <tylerr> Where you define the meaning behind the formatting as an attribute eh?
# [10:20] <anne> (not making xref global though, just let it apply to all current elements partaking in the definition/term stuff)
# [10:20] <tylerr> Interesting way of looking at it.
# [10:21] <Zeros> Should probably add a for attribute for referencing a local definition too
# [10:22] <anne> that can happen automatically by the UA
# [10:22] <tylerr> @longdesc ;-)
# [10:22] <Zeros> anne, how so?
# [10:22] * anne tries to find a pointer
# [10:23] <anne> http://www.whatwg.org/specs/web-apps/current-work/#dfn
# [10:23] <Grauw> anne, my problem with is that it also indicates ‘mood’, and not just terms. xref is nice, although there shouldn't necessarily be a need to cross-reference.
# [10:23] <anne> just marking up a term for the sake of it doesn't have much value imo
# [10:23] <tylerr> Ah hello Grauw. Now you've gone and made me start thinking before bed time! ;-)
# [10:24] <Grauw> tylerr, did I :)
# [10:24] <Grauw> I think <term> is common enough to be justified its own element
# [10:25] <tylerr> 01:25 here and you've got me thinking about the meaning behind something being italic, my brain doesn't normally do that at this hour :-D
# [10:25] <Grauw> plus, in combination with <dfn> it could actually be useful in referencing back to the definition (or a definition list somewhere)
# [10:25] <Zeros> anne, hmm. Okay.
# [10:26] <Zeros> Odd that the <dl> example shows both <dfn> nested in the <dt>, isn't that redundant since both mark it as the definition of the term?
# [10:26] <anne> introducing a new element is way more typing than the current mechanism for doing cross references
# [10:26] <Grauw> Zeros, I think that would be so, yes
# [10:27] <Grauw> except that maybe HTML5 redefines dl to be also appliccable to conversations etc
# [10:27] <anne> i think an attribute that applies to some elements you would typically use to mark up a term is more useful
# [10:27] <anne> Zeros, <dl> is defined to be a data structure
# [10:27] <Grauw> I always find the ‘length’ argument and ‘amount of typing’ not very convincing :)
# [10:27] <anne> Zeros, not just pairs of terms and their definitions
# [10:28] <anne> Grauw, and that for someone who advocates href=
# [10:28] <tylerr> I've always read <dl> as "data list".
# [10:28] <Grauw> anne, I advocate href=? :)
# [10:28] * anne got things mixed up maybe
# [10:28] <anne> HTML5 calls it description list
# [10:29] <hsivonen> Zeros: do you mean that SGML is an abomination? do you mean that HTML5 syntax is a abomination?
# [10:29] <Grauw> I probably just said that it was a nice idea, but I would not argue for it based on length alone
# [10:29] <anne> Grauw, conversations are done with <dialog>
# [10:29] <Grauw> aha
# [10:29] <tylerr> hsivonen: He's saying we should all go back to using Word to design our web pages. ;-)
# [10:29] <Grauw> http://www.w3.org/TR/html4/struct/lists.html#h-10.3
# [10:29] <anne> which does indeed use <dt> and <dd> inside for speaker and what they say...
# [10:29] <Grauw> HTML4 says ‘Definition list’
# [10:30] <anne> yeah, it was changed to match reality
# [10:30] <Grauw> I don’t know why HTML5 is changing that.
# [10:30] <Zeros> hsivonen, I meant what's evolved from HTML and XHTML is an abomination. Its half XML, half SGML, mostly wrong everywhere. Entities <,>,& aren't encoded in most places, /> in HTML docs that shouldn't be there if it was SGML, that kind of thing
# [10:30] <Grauw> might as well redefine to mean ‘a heading’
# [10:30] <tylerr> It's used in a larger scope than definitions.
# [10:30] <anne> people use <dl> for all kind of stuff
# [10:30] <Grauw> if you’re trying to match reality
# [10:30] <anne> mostly for grouping name/value stuff
# [10:31] <sbuluf> <term>, <dialog>, <haiku>, <car>, <employee>...endless series. and all hardwired, instead of externally definable via some schema language
# [10:31] <Zeros> tylerr, ...
# [10:31] <tylerr> I used a <dl> to express a transcript I was posting to a webpage a few days ago, that's a good example.
# [10:31] <hsivonen> Zeros: well, we have to deal with the real Web--warts and all
# [10:31] <tylerr> Zeros: :-)
# [10:31] <Zeros> hsivonen, of course
# [10:31] <Grauw> I think I’d prefer to keep it to the original specification, but I haven’t really thought about that :)
# [10:31] <anne> Grauw, UAs could certainly consider with a certain font-size to be a heading... Opera does that iirc
# [10:31] <tylerr> Zeros: It's late and I'm ornery, haha.
# [10:31] <Zeros> :)
# [10:32] <Zeros> sbuluf, <car> isn't a document construct though :p
# [10:32] <Grauw> there will always be incorrect usages, the specification should not try to cover them all, otherwise you might as well say that every element is as generic as a span
# [10:32] <anne> the specification should try to cover as much as reasonably possible
# [10:32] <sbuluf> zeros, right, neither <employee>, but they all are dastastructures, though
# [10:33] <tylerr> <noun>, <verb>, etc.
# [10:33] <anne> which is pretty vague, but I think so far it goes quite well :)
# [10:33] <Zeros> sbuluf, So transform them into HTML with XSLT
# [10:33] <anne> or invent a microformat
# [10:33] <Zeros> tylerr, sure, if we wanted to get that specific
# [10:33] <anne> so you don't need XML
# [10:33] <anne> or XSLT
# [10:33] * Lachy_ is now known as Lachy
# [10:34] <tylerr> Hey there Lachy.
# [10:34] <Grauw> The WHATWG specification isn’t redefining to be equivalent to ...
# [10:34] <Grauw> So why should it redefine <dl>.
# [10:34] <Grauw> Surely both have equal amounts of incorrect usage.
# [10:34] <Lachy> Hey tylerr
# [10:34] <sbuluf> zeros, thats kind of what i had in mind, precisely. each <section> says whare to insert, and structure, meaning, behaviour, etc, can be externally defined
# [10:34] <anne> prolly because the spec itself abuses <dl> too
# [10:34] <anne> "abuses"
# [10:35] <hsivonen> Grauw: I think it should redefine and to have the same semantics and default presentation
# [10:35] <Grauw> it’s funny when a spec uses things it itself describes :)
# [10:35] <anne> and maybe will be redefined in due course...
# [10:35] <Grauw> Well, I don’t think that’s a good idea.
# [10:35] <anne> Grauw, the spec also uses the cross references stuff
# [10:35] <anne> (as do several other specs, such as XMLHttpRequest)
# [10:36] <anne> (with a generator that outputs <a> around them though)
# [10:36] <Grauw> I can't find that xref attribute you mentioned or any mention of ‘cross reference’ in the spec...
# [10:36] <anne> Grauw, the idea was to introduce that to make the mechanism opt-in instead of opt-out
# [10:36] <anne> Grauw, it would also help with performance in browsers for dynamic updates
# [10:37] <Zeros> Grauw, docbook has one
# [10:37] <sbuluf> what is that xref thingie? first time i see
# [10:37] <tylerr> I'm wondering anne how much emphasis we'll be placing on "emotional" elements like and ? Are we leaving them alone for the most part?
# [10:37] <Grauw> I'm missing what it does exactly :)
# [10:37] <anne> Grauw, <dfn>test</dfn> test currently gives you a pointer from to <dfn>
# [10:38] <anne> Grauw, the proposal is: <dfn>test</dfn> test test
# [10:38] <Grauw> I see
# [10:38] <anne> only the second will give you a pointer
# [10:38] <Grauw> I’d say might as well use <term> then
# [10:38] <Grauw> :)
# [10:38] <Grauw> and automatically add xrefs
# [10:38] <anne> <dfn title="test test">test</dfn> blah would be another sample
# [10:39] <Zeros> sbuluf, moving all the abstractions out like you want to doesn't solve anything. You're just making XML in itself
# [10:39] <anne> and xref= would apply to , <code>, <samp>, , <abbr>, <var>
# [10:39] <anne> or something
# [10:39] <Grauw> do you not think it would actually be better to just use href?
# [10:39] <Grauw> it does not necessarily have to exist in the same document...
# [10:40] <anne> using this mechanism myself, it would be very inconvenient i think...
# [10:40] <Grauw> it starts to sound awfully much like XHTML2 :)
# [10:40] <anne> what you're suggesting does, yes
# [10:40] <Grauw> why, just use IDs
# [10:40] <Grauw> it's the same thing
# [10:40] <anne> it's way more typing
# [10:40] <Grauw> <dfn id="test">test</dfn> <term href="#test">test</term>
# [10:41] <Grauw> no it's not, only add a #
# [10:41] <anne> you'd use <a> I hope
# [10:41] <Zeros> it'd make more sense to use id since title doesn't usually imply uniqueness.
# [10:41] <Grauw> and you can make the id as cryptic and short as you want :)
# [10:41] * Parts: htmlr_ (htmlr@203.206.237.84)
# [10:41] <Grauw> anne, or an <a> element
# [10:41] <hsivonen> anne: does the CSS WG generator have a real parser or is it a regexp hack?
# [10:41] <Grauw> was just making the XHTML2 reference complete ;p
# [10:41] <anne> hsivonen, real parser iirc
# [10:41] <sbuluf> zeros, quite close to full xml, just a restricted subset, very much like xhtml. however, the clear separation of content, structure, meaning, etc, is, on one hand, very clear mentally, easy to grasp, learning curve shortener. on the other...did you ever consider the problem of doing wymiwys editors? would cdl be way easier than the current specs, with everincreasing complexity?
# [10:41] <Zeros> If <dfn title="foo">bar</dfn> is the only dfn allowed with that title then why not use id?
# [10:41] <Grauw> given that you want to put the xref attribute directly on the elements as well
# [10:41] <Zeros> The behavior of being unique already exists
# [10:42] <anne> Zeros, because yo uwant the term defined to be accessible?
# [10:42] <Grauw> also, I think it’s actually very good if every term had an ID
# [10:42] <Grauw> it makes it lots easier to reference it
# [10:43] <Zeros> anne, Provide the title too. I'm saying that making the title attribute the link specifier doesn't make sense since you can't get to it with a simple dom call in legacy browsers (getElementById however does work)
# [10:43] <anne> yet more typing
# [10:43] <Grauw> (not that I’m saying the id attribute should be required)
# [10:43] <Zeros> If typing is all this is about we should not use <video> and instead use <v>
# [10:43] * anne agrees that having ID on <dfn> would be nice
# [10:44] <sbuluf> zeros, more particularly? why are we forcing end-users all over the plante to have to learn html, at all? shouldn't they be able to write content without *ever* having to see code? and could we do that with the corrent very complex specs? how?
# [10:44] <anne> Zeros, <video> is not something you'd use as often as terms
# [10:44] <Grauw> because <dfn> is a separate element, you could just auto-generate an ID, wouldn’t be a need to type
# [10:44] * anne isn't sure terms are needed though
# [10:44] <anne> the only real use case is technical documents
# [10:44] * Joins: Shunsuke (kuruma@219.110.80.235)
# [10:44] <Grauw> anne, which there are a *lot* of on the internet
# [10:44] <Zeros> anne, I don't think the amount of typing should change what we use for attributes and element names.
# [10:44] <Grauw> plus ‘je ne sais qois’
# [10:44] <anne> Zeros, well, then we disagree
# [10:45] <Grauw> that’s hardly limited to technical documents
# [10:45] <Grauw> that example
# [10:45] <anne> that's not a term
# [10:45] <tylerr> sbuluf: It's a big issue we're facing at work right now. We're helping a client develop an internal publishing tool that blends content editing/publish with page development. We're talking WYSIWYG on steroids and it's a VERY complex and mind-boggling task.
# [10:45] <Zeros> anne, why are they adding the <header> element and not <h>?
# [10:45] <Grauw> it is, a foreign term
# [10:45] <Grauw> that’s why it’s italicised
# [10:45] <anne> that's just a foreign language phrase
# [10:45] <sbuluf> <Zeros> If typing is all this is about we should not use <video> and instead use <v> <--if we had wymiwys editors, then we would never worry about how much to type, since we would never ever need to see the code
# [10:45] <anne> Zeros, same reason, you don't use it so often
# [10:46] <Zeros> I don't see dfn used very often on most sites
# [10:46] <sbuluf> tylerr, is it even possible at all, with today's specs being so complex?
# [10:47] <anne> Zeros, I already mentioned I'm not completely convinced this is needed, although it can be useful for technical documents
# [10:47] <tylerr> Also I think code should be readable enough to where I can sim through the source and see the <article><section><para><etc>, it helps developers locate blocks of data much quicker than seeing smaller <a><s> tags.
# [10:47] * anne uses <dfn> a lot in specs
# [10:47] <Grauw> me too
# [10:47] <Grauw> in my definition, foreign words would be included in <term>
# [10:47] <Grauw> after all, you can use <dfn> on them too
# [10:47] <tylerr> sbuluf: Nope! That's why I'm here and looking to influence the development of this publishing platform to go along with what this WG comes out with.
# [10:47] <Grauw> the basic function of them is the same
# [10:48] <anne> tylerr, yeah, indeed, code should be readable
# [10:48] <sbuluf> tylerr, if we ever need to see the soruce, at all, then to expand <v> to <video>, should be trivial
# [10:48] <tylerr> s/sim/skim
# [10:48] <anne> sbuluf, that is not a common authoring practice
# [10:48] <Grauw> do consider that whatever names you give them, to a chinese person it’s still gibberish ;p
# [10:48] <anne> sbuluf, please take into account the real world here...
# [10:48] <Grauw> but anyway, I also agree there’s benefit in having short, but not too short names
# [10:49] <tylerr> <?> for a copyright element would go over well then ;-)
# [10:49] <sbuluf> anne, true. which is why i can not quite contribute to this group, other than just marginally.
# [10:50] <anne> sbuluf, you don't live in the real world? :)
# [10:50] <Zeros> tylerr, we should add that make every XML parser choke on it.
# [10:50] <tylerr> I'm of the camp that code should be beautiful and functional at the same time. I enjoy skimming code that envokes a sense of aesthetics.
# [10:50] * tylerr chuckles
# [10:51] <sbuluf> anne, i do. and i know about installed bases, and chaos theory, and error perpetuation. hence, i think we need another language to replace html from scratch, before we are all doomed by ever increasing legacy
# [10:51] <sbuluf> anne, hence, i'm just marginal here =P
# [10:51] * anne thinks it's better to try to understand the legacy first
# [10:51] <Grauw> sbuluf, I ask you, do you think than that this group is the right place for you to be, or that you’re wasting our time?
# [10:51] <tylerr> I prefer <xlink> over <a>, and <section> over <s>. I love reading code like a novella.
# [10:51] <Zeros> sbuluf, that was XHTML2, which no one adopted...
# [10:51] <anne> replacing it will be hard otherwise
# [10:52] <anne> XHTML2 is not what sbuluf is talking about I think
# [10:52] <anne> at least, I hope not
# [10:52] <Grauw> it’s not.
# [10:52] <tylerr> Sure anne. We need to have a clear understanding of the semantics behind the current elements, then take it from there.
# [10:52] <Zeros> anne, I meant in the sense they tried to fix everything and ignored what they might break. They wanted a new language
# [10:52] <tylerr> Sort of an Oxford English version of HTML4.01
# [10:52] <Zeros> anne, which is what sbuluf is suggesting
# [10:53] <sbuluf> grauw, i just had a interest in clear definition of scope, myself. i will not continue after that. i mentioned other stuff just cause i was here and some could be of use. it was friendly, though, not my intention to stop this, since is impossible.
# [10:53] <Grauw> I'm not trying to be not-nice, but just asking an honest question :)
# [10:53] <sbuluf> zeros, anne, xhtml2, however, has some flaws already. i think it could be done better. so i have to cook my own, can't even join that, they would not listen.
# [10:53] <anne> But XHTML2 is actually just a minor update to HTML, it's not really revolutionary... It won't be adopted because of that I think.
# [10:54] <sbuluf> grauw, nono, i understood it that way, and your question was logical
# [10:54] <anne> (Mostly because it's a minor update, not well defined and not backwards compatible.)
# [10:54] <tylerr> Anything we do here cannot break today's pages.
# [10:54] <Zeros> anne, What you suggest is impossible. You can't fix all the problems with HTML4 and make it backwards compatible at the same time.
# [10:54] <tylerr> There shouldn't be a "join us or die" mentality.
# [10:54] <tylerr> :-)
# [10:55] <anne> Zeros, HTML5 is doing that...
# [10:55] <sbuluf> tylerr, right, hence my questions here yesterday. my interest was delimitation of scope
# [10:55] <tylerr> Ah interesting sbuluf I was out all day with the g/f so I missed that.
# [10:55] <anne> Zeros, for my definition of "problems with HTML4" anyway
# [10:56] <Zeros> anne, For you, likely not for the XHTML2 group.
# [10:56] <anne> XHTML2 didn't fix any of the problems
# [10:56] <Hixie> i'd recommend avoiding the term "backwards compatible" in this discussion, as it is somewhat ambiguous. better to use the terms mjs defined in the principles.
# [10:56] <Grauw> i agree :).
# [10:57] <Grauw> (with Hixie)
# [10:57] * anne waits for someone to say +1
# [10:57] <Zeros> anne, sure they did. <img> was given alt text in the body which was definitely needed. They removed all the presentational attributes and elements once and for all.
# [10:57] <Zeros> Added <h> and <section>
# [10:58] <anne> Zeros, "definitely needed"? People hardly ever use alt="" and when they do a string of characters is mostly enough.
# [10:58] <sbuluf> zedros, compared with the xhtml2 group, i'm the che guevara in terms of revolutionarity =P
# [10:58] <Zeros> anne, A string of characters is all that is allowed
# [10:58] <tylerr> Would it be at all crazy to suggest some persona work so that everyone has a more clear understanding of whom this spec is written for?
# [10:58] <anne> Zeros, some accessibility indoctrinated people might complain about it daily, but it's not too bad
# [10:59] <Zeros> anne, If <audio> and <video> warrant alternate content in the body then it should be provided for img as well
# [10:59] <anne> Zeros, HTML5 also removed all presentational stuff
# [10:59] <Grauw> there’s always <object>. And <img> can get alt text in the body once XHTML really starts to be adopted in all browsers
# [10:59] <tylerr> We could say "people", but there are various groups of people that would be utilizing this. We're talking designers, developers, publishers, producers, etc.
# [10:59] <anne> Zeros, it's impossible to change <img>
# [10:59] <anne> Zeros, except maybe in XHTML5 but I don't really see the major advantage it gives. And indeed, <object> is there
# [10:59] <Grauw> so HTML6 or HTML11 can define alt text in the body.
# [11:00] <Grauw> *XHTML6 or XHTML11
# [11:00] <anne> tylerr, everybody concerned with the "browsable" web + other folks
# [11:00] <Zeros> anne, It wasn't for the XHTML2 group. Like I said, they fixed all these things ignoring compatibility with legacy UAs. Fixing everything for HTML5 is impossible if you keep that principal
# [11:00] <tylerr> Sure anne, who are those other folks, and what are their needs?
# [11:01] <Zeros> HTML5 will forever suffer from the mistakes made with HTML4 to ensure it works in older browsers
# [11:01] <tylerr> That I feel is what (and who) we need to personify.
# [11:01] <Grauw> zeros: indeed.
# [11:01] <Grauw> or actually: only as long as reality requires it.
# [11:01] <sbuluf> if something defines the scope of this group, is, roughly "back compat" (sorry, hixie, just rough and short general expression)
# [11:01] <anne> Zeros, you can drop stuff on the authoring side but still require UAs to support it. Dropping the legacy completely is impossible. We have to support the content mankind created...
# [11:01] * Parts: icaaq (icaaaq@85.228.55.162)
# [11:02] <sbuluf> zeros, exactly. errors forever.
# [11:02] <Grauw> what I mean with that is, HTML5 is designed with backwards compatibility with today’s browsers in mind
# [11:02] <Grauw> if tomorrow’s browsers for HTML6 don’t exhibit certain problems that HTML5 has to work around, then those ugly parts can be removed in HTML6
# [11:02] <tylerr> Anyway, enough of me espousing my own opinions. Lovely discussion tonight everyone, have a wonderful time and I'll see you all in a good 7 or 8 hours. :-)
# [11:03] <Grauw> byebye
# [11:03] <sbuluf> later, tylerr
# [11:03] <Zeros> anne, Well, browsers have to support it.
# [11:04] <anne> Zeros, that's what I said, yes.
# [11:04] <Grauw> browser support is something that changes over time. old content on the web doesn't
# [11:04] <Zeros> We could also add <image> which honestly makes sense with <audio> and <video>
# [11:04] <anne> Starting from scratch won't help with that though.
# [11:04] <Zeros> Might as well hit all three bases at the same time :p
# [11:04] <anne> Zeros, <image> is actually turned into <img> during parsing
# [11:04] <sbuluf> starting from scratch, would efeectively mean to fork the web
# [11:05] <Grauw> I think you can divide legacy in two parts: legacy which is there to support older content, and legacy which is there to support older browsers.
# [11:05] <anne> sbuluf, some university is working on that...
# [11:05] <Zeros> anne, which legacy UA added that?
# [11:05] <Grauw> anne, browser support <image>?
# [11:05] <Grauw> *browsers
# [11:05] <sbuluf> anne, the clean state internet thing, i think you mean. but that is *internet*, not web
# [11:05] <anne> in text/html they do, yes
# [11:05] <Grauw> cool :)
# [11:05] <anne> it's a syntax error, mind you ;)
# [11:06] <sbuluf> anne, clean slate, sorry
# [11:06] <anne> sbuluf, oh right, that's prolly true
# [11:06] * Joins: ROBOd (robod@86.34.246.154)
# [11:06] <anne> Zeros, dunno, prolly Netscape x or IE x
# [11:06] <Zeros> anne, how often is the <image> tag used though?
# [11:06] <Grauw> why would one create a new internet :/
# [11:06] <anne> Zeros, enough to be part of the parsing algorithm
# [11:06] <Zeros> Grauw, we already have internet2 :)
# [11:06] <sbuluf> anne, good and interesting thing, imho, altough to change physical wires and protocols, is even way more difficult to ever happen than to change just the web
# [11:07] <Grauw> let's just implement IPv6 everywhere and all be happy :)
# [11:07] <Zeros> anne, There's plenty of things <bgsound> though that are very rare. Why not just overload <image> to be <image>content</image>
# [11:07] <Zeros> things such as
# [11:08] <sbuluf> grauw: http://cleanslate.stanford.edu/
# [11:08] <anne> Zeros, because that would break stuff
# [11:08] <anne> Zeros, <bgsound> is also part of the parsing algorithm iirc
# [11:09] <Grauw> sbuluf, thanks, I'll give it a read
# [11:09] <anne> I checked, <bgsound> is part of the parsing algorithm
# [11:09] <Zeros> anne, what would it break? <image src="foo">sometext</image> with an optional end tag would not break anything in legacy UAs. They'd see both the alternate content and the image, but that's not really breaking.
# [11:10] <sbuluf> if we had basically just a bunch of <section>'s, the parsing algorythm would be pretty simpler, right?
# [11:10] <Zeros> <image src="foo"> would still be valid in a legacy UA
# [11:10] <Zeros> anne, your parser mangling would still be valid since the src attribute is the same
# [11:10] <anne> Zeros, try to study how parsing works before making such claims
# [11:11] <anne> <image> is not valid, it's a syntax error...
# [11:11] <Grauw> sbuluf: not more simple than any other XML document
# [11:11] <Zeros> anne, How is that different than <section> which is also a syntax error in older UAs?
# [11:11] <Grauw> anne: we could rename <img> to <image> without creating browser compat problems :)
# [11:11] <Zeros> the tag doesn't exist
# [11:11] <anne> well, XML is fricking complex due to the internal subset
# [11:11] <sbuluf> grauw, right. but simpler than current html algorythms, i meant.
# [11:11] <Zeros> you're correcting it to <img>
# [11:11] <Zeros> what's the problem?
# [11:11] <Grauw> sbuluf, anything is simpler than HTML parsing :)
# [11:11] <anne> Grauw, that would invalidate lots of content for no reason
# [11:12] <anne> HTML parsing isn't that complex
# [11:12] <Grauw> anne, I meant it as a joke ;p
# [11:12] <anne> fair enough
# [11:13] <Zeros> anne, Opera 9 is fine with <image src="">...</image>
# [11:13] <anne> Zeros, learn how parsing works, introducing an optional end tag like that wouldn't work
# [11:13] <sbuluf> grauw, if parsing was tremendously simpler, then perhaps what browser vendors do could become less important (and show stopping), since perhaps anyone could make one
# [11:13] <Grauw> Zeros, please test in IE6, because that’s what’s really relevant :)
# [11:13] <Zeros> anne, how is it different than XML?
# [11:13] <Grauw> sbuluf: I’m not following you here
# [11:13] <sbuluf> grauw, and perhaps we could finally have wymiwyg editors in the bargain, hence avoiding end-users the need to ever see the code
# [11:13] <Grauw> parsing is only a tiny little bit of showing the document to the user
# [11:14] <anne> Zeros, how can you tell whether you have to do with an oldschool <image> element or a new <image> element which requires a closing tag?
# [11:14] <anne> Zeros, that's just introducing unneeded complexity for no real benefit
# [11:14] <sbuluf> grauw, ahh. any place where i could learn about percentages of code per task?
# [11:14] <anne> also, define "Opera 9 is fine"
# [11:15] <anne> preferably by providing a pointer to a testcase
# [11:15] <Zeros> anne, if you defined it as strictly inline content since that's where <img> is allowed then next block element or </image>
# [11:15] <anne> what?
# [11:15] <Zeros> anne, the same way you close
# [11:15] <anne> that would break lots of content currently using <image>
# [11:16] <Zeros> anne, No. If you hit another block element and there was no </image> you assume its empty. If you hit </image> before hand then what proceeded it is the content of the <image>
# [11:16] <Zeros> That doesn't change how <image> or <img> works at all
# [11:16] <sbuluf> anne, perhaps you...side request: any page where i could learn about how much of a browser code and complexity belongs, by taks (parsing, rendering, etc)
# [11:17] <anne> Zeros, that requires look ahead and that's not really acceptable
# [11:17] <Zeros> Why is that not acceptable?
# [11:17] <Hixie> that would require backtracking during parsing which is susceptible to XSS attacks when combined with user-provided data and man-in-the-middle DOS attacks
# [11:18] <Grauw> sbuluf, I don’t know if it can be quantified like that, it'll differ per-browser
# [11:18] <anne> sbuluf, HTML5 should describe most of the parsing stuff
# [11:18] <Grauw> what you could do is check out the Mozilla source code and look at how much disk space of source code each component occupies
# [11:18] <sbuluf> grauw, right. i know so little about it, though, that even aproximations would help
# [11:18] <Zeros> Hixie, how is backtracking in the parser going to open an XSS hole with user data and a man in the middle?
# [11:19] <Zeros> You're just shifting the nodes to be children of the <image> instead of the parent node.
# [11:19] <anne> sbuluf, together with other people I wrote an open source Python implementation of the HTML5 parser, you could play with that...
# [11:19] <Grauw> sbuluf: just think of the many other technologies involved, CSS (which is hugely complex compared to parsing algorithms), building a DOM from parsed XML, all the UI, network technologies, image rendering, plugin architecture
# [11:19] <Grauw> parsing is just one of the many bits.
# [11:19] <sbuluf> anne, more tgeenrally..why are browsers so big and complex? which parts are the biggest and mor complex? any place where i could learn about composition, percentages?
# [11:20] <anne> sbuluf, trac.webkit.org and lxr.mozilla.org maybe...
# [11:20] <Hixie> Zeros: actually yeah you're right, with <image> it wouldn't be an XSS attack, it would just be an alternate content replacement, which is no big deal really
# [11:20] <sbuluf> anne, grauw, yes, i ment whole browsers, not just parsers
# [11:20] <sbuluf> anne, thanks
# [11:20] <Hixie> Zeros: still, look-ahead is extremely expensive and browser vendors wouldn't want to add that kind of feature.
# [11:20] * Joins: karl (karlcow@128.30.52.30)
# [11:21] <Zeros> Then we need better semantics for <object> when used for images.
# [11:21] <anne> such as?
# [11:21] <Zeros> "<object> should be semantically equivalent to <img> when data points to an image resource and the remote resource is loaded correctly"
# [11:21] <anne> but what's the use case really?
# [11:22] <Grauw> yes, what’s the use case for <img> <video> and <audio> if you could just use <object> ;p
# [11:22] <Zeros> anne, alternate content as with the inside of <video>
# [11:22] <Zeros> Since you can't do it with <img>, you'd be stuck with <object> which is a really generic remote resource since it can be anything
# [11:23] <anne> When is alt= not good enough?
# [11:23] <Grauw> what’s the problem with that, Zeros?
# [11:23] * anne rarely encounters such a case
# [11:23] <Zeros> anne, why shouldn't <video> just have alt then?
# [11:24] <anne> it's considered better practice to not hide content in attributes
# [11:24] <Grauw> Zeros, alt is there for compatibility with HTML parsing algorithms that browsers employ, simple. It’s not ideal, but it works.
# [11:24] <Zeros> if <audio> or <video> should be allowed complete descriptions why not images? And what's the harm is stating that <object> is semantically equivalent to an <img> when it points to one?
# [11:24] <anne> in the case of <video> it allows some fallback for legacy browsers
# [11:24] <Grauw> Zeros: wouldn’t that be stating the obvious?
# [11:24] * anne would expect anything besides fallback to be used inside <video>
# [11:25] <anne> wouldn't*
# [11:25] <Grauw> alternate text is fallback
# [11:25] <hsivonen> Zeros: compatibility trumps consistency
# [11:25] <anne> fallback for legacy browsers*
# [11:25] <Zeros> Grauw, Not necessarily since object could be anything.
# [11:25] <Zeros> If you just look at the object tag itself its very generic
# [11:25] <Grauw> if an object includes an image, it's an image
# [11:26] <Zeros> its an object that embeds an image, its not the same as <img>
# [11:26] <Grauw> what purpose is there to indicate it with a tag, when really it's the included content that really makes it an image?
# [11:26] <hsivonen> "22:53 * DanC is sorry for <object>; thinks it's a pretty big waste of everybody's time
# [11:26] <hsivonen> "
# [11:26] <Zeros> hsivonen, The argument wasn't either though. It was that I'd be more complicated in the parser to deal with it.
# [11:26] <hsivonen> (Can't remember which day that was from)
# [11:26] <Grauw> hsivonen, how does he mean that?
# [11:27] <sbuluf> <Grauw> what purpose is there to indicate it with a tag, when really it's the included content that really makes it an image? <--same idea for using just <section>'s =P
# [11:27] <Zeros> And they screwed up object when they allowed the classid nonsense
# [11:27] <Grauw> sbuluf: no it’s not
# [11:27] <sbuluf> grauw, instead of ol, ul, table, p, car, employee...
# [11:27] <hsivonen> Grauw: I guess you have to ask DanC for the details. I can observe that <object> implementability sucks.
# [11:28] <anne> sbuluf, somehow your idea of a new markup language doesn't strike me as particularly useful to me as an author
# [11:28] <Grauw> sbuluf, that is not inherent to text
# [11:28] <Grauw> even not to a human reader, if it is not supported by certain presentation
# [11:29] <sbuluf> anne, souldn't anyone, including grandma and grandpa be able to write perfectly valid content, ready for the future and all, withour even ever having to learn the language? how could we ever achieve that with current specs complexity?
# [11:30] <anne> sbuluf, editors?
# [11:30] <sbuluf> anne, yes
# [11:30] <Zeros> sbuluf, browsers solved that a long time ago by allowing soup.
# [11:30] <sbuluf> anne, i mean wymiwyg edotors
# [11:30] <Grauw> hsivonen, can't find it in the logs on krijnhoetmer.nl
# [11:31] <Zeros> sbuluf, if your grandma can get markup that's almost right or close to it the browser does the rest.
# [11:31] <Zeros> They don't need to be that concerned with the spec
# [11:31] <Grauw> that's too bad
# [11:31] <hsivonen> Grauw: it was on #whatwg back in the WhatBot days
# [11:31] <Grauw> ah
# [11:31] <Grauw> that DanC is Dan Connolly, right?
# [11:31] <anne> yes
# [11:31] <hsivonen> Grauw: so the /wii claimed
# [11:32] <Grauw> is whatbot archived somewhere?
# [11:32] <sbuluf> zeros, if you expect good code, high-level machine processability (read semweb), etc...then i think it is important.
# [11:32] <hsivonen> Grauw: I don't know. Charl and Krijn may have a plan
# [11:33] <Grauw> hsivonen: the DanC here doesn’t necessarily have to be the same as on the whatwg list :)
# [11:33] <anne> DanC isn't on the WHATWG list
# [11:33] <sbuluf> only one danc around, afaik
# [11:33] <Grauw> too bad, I would have liked to see the context
# [11:33] <Grauw> *whatwg IRC
# [11:33] <anne> http://whatbot.charlvn.za.net/ looks dead
# [11:34] <Zeros> sbuluf, well machines already process it. Anyway, the web in terms of code quality sucks. Replacing it with some other language probably wouldn't change that. It'd just get fragmented and messed up again and the new browsers would get to deal with it.
# [11:34] * Grauw nods
# [11:34] <anne> yup, happened to XML
# [11:34] <anne> or happens
# [11:35] <sbuluf> zeros, isn't hand coding the main source of bad code in the web?
# [11:35] <anne> all code derives from "hand coding"
# [11:35] <sbuluf> what if nobody had to hand code anymore (or even have to learn the languages, for that matter)
# [11:35] <anne> and since people are flawed, it will always go "wrong"
# [11:36] <sbuluf> anne, what is editors themselves would not allow aerrors?
# [11:36] <anne> we better just accept that and design the language around it
# [11:36] <Grauw> sbuluf: you always have to learn something
# [11:36] <sbuluf> *if
# [11:36] <anne> sbuluf, editors are made by people
# [11:36] <sbuluf> anne, bugs aside, of course
# [11:36] <sbuluf> i mean design
# [11:36] <anne> bugs will always be there
# [11:37] <sbuluf> yep, and can be fixed, just like always
# [11:37] <anne> yes, but at that point you already have deployed content
# [11:37] <Grauw> bugs are being fixed though, e.g. with regard to <object>
# [11:37] <anne> you have to take into account that it won't be flawless and design for that
# [11:37] <Grauw> sometimes it's a problem, but often it's not
# [11:38] <sbuluf> if you are already in a level of processability like that allowed say by xml...then could you not provide an external routine to upograde legacy content to the newest version?
# [11:38] <anne> now <object> finally has a halfdecent spec we might get some more fixes, yes...
# [11:38] <anne> sbuluf, you'd have to solve the halting problem first
# [11:38] <Grauw> I'm pretty sure Mozilla's not going to build in back compat stuff in their SVG implementation just because they released a half-finished one in Firefox 1.5
# [11:38] <Hixie> i'm curious as to how you'll create an editor that always generates the write markup
# [11:39] <Hixie> is it to be omniscient?
# [11:39] <sbuluf> hixie, so am i! =P
# [11:39] <Hixie> anne: only half decent? ;-)
# [11:39] <Hixie> er
# [11:39] <Hixie> "right" markup
# [11:39] <Hixie> oops
# [11:39] <anne> Hixie, it has red boxes and such :)
# [11:39] <sbuluf> hixie, but my main worry, is that i do not see anyone even trying today
# [11:39] <Hixie> anne: fair point!
# [11:40] <Hixie> sbuluf: oh i know people are trying, i've spoken to them. they just don't know how.
# [11:40] <Grauw> and Microsoft also didn't build in back compat stuff in their XSLT implementation for their old IE5’s XSLT WD implementation
# [11:40] <sbuluf> hixie, perhaps my cdl model would be simple enough to allow it, as opposed to the current complexity of (x)html specs
# [11:40] <Hixie> sbuluf: you can only spend so many months prototyping doomed semantic editors before business concerns force you to bite the bullet and make "WYSIWYG" ones
# [11:40] <Hixie> sbuluf: maybe
# [11:40] <sbuluf> hixie, if so, then again the problem is...back compat and legacy, or new stuff?
# [11:41] <Hixie> sbuluf: if so, a simple transform from your language to HTML would then solve the problem :-)
# [11:41] <anne> sbuluf, I wonder if you can really design a language less complex that solves the same use cases. But it would be nice...
# [11:41] <Grauw> that is, if his language is XML-based then the transformation would be simple ;p
# [11:42] <sbuluf> anne, so do i. i would like to gather some serious people to...at least try!
# [11:42] <Hixie> doesn't have to be XML
# [11:42] <anne> if it's XML-based it won't be flawless
# [11:42] <Hixie> so long as there's a parser for it
# [11:42] <Hixie> and a serialiser from that to HTML
# [11:43] <sbuluf> what scares the bejesus out of me, is that i do not see anyone even trying
# [11:43] <sbuluf> i'm no expert, even a techie, myself...but who else is doing such things?
# [11:44] <hsivonen> I'd love to see oXygen grow a Mathematica-like view to editing XHTML
# [11:44] <hsivonen> Etna certainly is interesting
# [11:44] <Hixie> like i said. i know people are trying, i've spoken to them. they just don't know how to do it. they can only spend so many months prototyping doomed semantic editors before business concerns force them to bite the bullet and make "WYSIWYG" ones.
# [11:44] <sbuluf> hixie, wat if we could leave bussiness out of the equation, altogether?
# [11:45] <anne> there'd be no funding
# [11:45] <Hixie> then they'd starve and die, i guess.
# [11:45] <sbuluf> it would have to be a foss sort of spec making, right
# [11:46] <Grauw> I don’t think that you can’t make business if your editor isn’t WYSIWYG
# [11:46] <sbuluf> but would that avoid the problem, if people contributed for free, and we could keep bussiness out of it?
# [11:47] <Grauw> If you take Word for example, there’s tons of people who just click the center and bold buttons and up the font size when they want to create a heading
# [11:47] <hsivonen> The way I see it is that a "semantic" editor should expose the document tree but should allow new paragraph to be created by pressing return instead of typing
# [11:47] <Grauw> yet especially companies are giving trainings to their employees to use the heading functionality in Word
# [11:48] <sbuluf> graw, but that's what you see, not what you mean
# [11:48] <Grauw> so that e.g. their documents conform to company style
# [11:48] <Hixie> sbuluf: Free or Open Source software still has to have a business there, or the people have to have other jobs -- but yes, you could maybe find volunteers willing to prototype new UI ideas for semantic editors. I encourage you to start such a project.
# [11:49] <sbuluf> hixie...introduce me to all your fiends! i'm not even a programmer, myself. help needed
# [11:49] <Grauw> no, once you say 'it's a heading' you indicate what you mean (‘WYSIWYM’ or ‘WYMIWYG’), and not what you see (WYSIWYG)
# [11:49] <Hixie> my friends who have knowledge for making editors are all working on editors already
# [11:50] <sbuluf> hixie, they, unfortunately )1 want money 2) assume current specs (with which i think the task is just about impossible
# [11:51] <sbuluf> right?
# [11:51] <Grauw> If browsers provide a generic control to input semantic markup, I think you can get people to adopt that fairly quickly. Schools will teach it, and companies will give trainings.
# [11:51] <Grauw> just like they now do so for Word
# [11:51] <Grauw> I learned to use ‘Heading 1’ and not ‘bold center font size 24’ for heading in high school
# [11:52] <Zeros> Hixie, kudos on killing off all the ActiveX/IE related properties of <object>
# [11:52] <Grauw> (iirc :))
# [11:52] <sbuluf> grauw, i think so too. the problem is that current specs are way too complex for that, imho. on top, these current specs were not thought with editing in mind, for ages
# [11:52] <Hixie> sbuluf: they want food and a place to live, and to have a happy life; beyond that i doubt they have any fixed requirements.
# [11:52] <hsivonen> Grauw: Word is easier to create a UI for because there is a sequence of blocks and arbitrary nesting of blocks is not allowed
# [11:52] <Grauw> sbuluf, I don't see how really
# [11:53] <Grauw> hsivonen, you can't arbitrarily nest elements either
# [11:53] <Hixie> sbuluf: if you can make a new language that is easy to make a UI for, then you just need to define a mapping from that language to HTML and back again and you're done.
# [11:53] <Hixie> sbuluf: that language can be proprietary, an internal aspect of the editor.
# [11:53] <sbuluf> hixie, by "money" i meant just that, right. burt would they, or instance, be willing to try a new spec for doing it?
# [11:53] <Hixie> sbuluf: i'm sure they've even tried writing new specs themselves for it
# [11:54] <sbuluf> hixie, could you contact me, then?
# [11:54] <Grauw> I think Hixie is a busy man.
# [11:54] <Grauw> :)
# [11:54] <sbuluf> i'm sure he is
# [11:54] <Hixie> sbuluf: like i said, they're already working on editors full time, it's not like they're going to additionally work unpaid on other editors in their free time
# [11:55] <Hixie> having the same hobbies as fulltime work is not conducive to a healthy lifestyle
# [11:55] <Grauw> what I mean is, you can do the research and contact them yourself :)
# [11:55] <sbuluf> hixie, right, sorry, so the money part does not allow for meaningful interaction
# [11:56] <sbuluf> grauw, not easy even to find them. and i can do brainstorming, right, but only up to some point. no expert myself.
# [11:56] <anne> sbuluf, if you have an idea that's substantially better than what's out there just publish it and ask for comments
# [11:57] <anne> sbuluf, if people like it they might join you in some project
# [11:57] <Grauw> Daniel Glazman is one person with a lot of experience developing editors. His Etna editor, uses existing XML schema languages (I think RelaxNG) with some extensions that are particularly useful for editing, in combination with CSS. There are others too.
# [11:57] <anne> sbuluf, trying to find commitment without having proven anything seems like an impossible task
# [11:57] <sbuluf> anne, trying to at the moment, right. (those very beta pages you saw are part of that)
# [11:57] * anne didn't see anything
# [11:57] * Quits: Zeros (Zeros-Elip@69.140.48.129) (Quit: Leaving)
# [11:57] * anne thinks xopus.com is pretty good
# [11:57] <sbuluf> grauw, daniel was the first person i wanted to contact, right, also lachy here has some interest.
# [11:58] <sbuluf> anne, sorry: http://www.teoriadetodo.com.ar/fips/specs/cdl/anatomy.htm
# [11:58] <sbuluf> i thought you have seen them
# [11:58] <Hixie> sbuluf: they've already spent months trying to do this; unless you have a clearly compelling idea for how to solve the problem, i doubt they'd be interested in investing time trying to understand it (as they'd probably have already tried it themselves)
# [11:58] <sbuluf> anne, i checked xopus, interesting, right
# [12:00] <Grauw> Anne, heh, Q42 :)
# [12:00] <Grauw> In Firefox it tells me I can't use it. In IE it tells me I can't be blocking popups (which it does by default).
# [12:00] <sbuluf> hixie: almost empty content authoring language (just <section>, basically), with hooks to externally define presentation, meaning, datastructure, behaviour, etc. clean separation of content from everything else (css style). that would be the core, and imho, simplifies the editing task.
# [12:00] <anne> yeah, disclaimer on my about page :)
# [12:00] <Grauw> If this were a forum, I’d be gone by now ;p
# [12:01] <MikeSmith> oXygen XML editor (hsivonen mentioned earlier) has a lot of interesting features - http://www.oxygenxml.com/
# [12:01] <sbuluf> MikeSmith, thanks, xopus, via anne, was interesting too
# [12:01] * anne doesn't really see how sbuluf's proposal solves any problem
# [12:02] <Hixie> sbuluf: my understanding is that that kind of thing has been tried, and not found to be successful as a base on which to create a useable editor. But if you can show otherwise, then that would be great.
# [12:02] <Grauw> Etna does that, to some extent.
# [12:02] <Grauw> I mean, separating out the styles
# [12:02] * Grauw really excited about Etna ;p
# [12:03] * Quits: tylerr (tylerr@24.16.148.66) (Quit: Leaving)
# [12:03] <sbuluf> hixie, anne, i'll try. thanks for your time, btw. lachy and daniel glazman might be interested as well.
# [12:03] <Hixie> the test is "can your mum use it?"
# [12:03] <Hixie> anyway, i should go to bed
# [12:03] <Hixie> nn
# [12:03] <sbuluf> hixie, definitely. granda and grandpa, to be precise.
# [12:03] <Grauw> mum is good enough
# [12:03] <Grauw> grandpa and grandma will die soon
# [12:04] <Grauw> before it's standardised :)
# [12:04] <sbuluf> =P
# [12:04] <MikeSmith> my mum is an kernel programmer
# [12:04] <sbuluf> (see what i meant, grauw?)
# [12:05] <sbuluf> anne, i'd need to write some more on the editing aspect of things.
# [12:05] <sbuluf> anne, i can attempt to explain here now, however, if you wish
# [12:06] * Grauw shrugs * sbuluf, there’s plenty of grandfathers and grandmothers having careers in computer science as well.
# [12:06] <sbuluf> =P
# [12:07] <sbuluf> we could still move beta testing to nurseries
# [12:10] <hsivonen> a guy working for a POS vendor told me they have a requirement that an eight-year-old has to be able to operate their product
# [12:11] <sbuluf> today's kids can program networks when 3 y/o. scary. but yes, kids are the other beta testing ground
# [12:12] * MikeSmith imagines a row of eight-year-olds working the cash registers at his local supermarket
# [12:12] * Quits: st (st@62.234.155.214) (Quit: st)
# [12:13] <sbuluf> hsivonen, weirdly, an roughly...the lenght of the documentation needed for them to undertand it (which is never exactly zero, no matter how good you might do it), can work as a rough indicator too.
# [12:15] <sbuluf> hsivonen, which was an argument i had with tim berners lee, btw. i said that before keeping work on semantic web stuff, a "end-user's manual" should be written, screenshots and all
# [12:16] <Grauw> semantic web stuff is not meant for end-users
# [12:16] <Grauw> it's a backend thing
# [12:16] <sbuluf> grauw...but it should be usable by end users.
# [12:17] <hsivonen> Grauw: haven't you heard the blue sky talk?
# [12:17] <Grauw> normal users should only have to deal with tools
# [12:17] <hsivonen> Grauw: ah. tools will save us
# [12:17] <Grauw> not with URIs and RDF/XML
# [12:17] <Grauw> hsivonen, >.<
# [12:17] <hsivonen> I see
# [12:18] <sbuluf> grauw, but precisely...i wanted to see en end-user manual, an UI anyone could use, etc, without ever having to learn any backend stuff.
# [12:18] <sbuluf> "what do i show grandma?"
# [12:18] <Grauw> if a user types in Google Maps that he wants to travel from New York to Paris, it's up to the tool (Google Maps) to interpret the data from data sources and provide the user with meaningful things, such as Pizza Hut icons
# [12:18] * hsivonen notes that hCal addresses the canonical Semantic Web use case
# [12:19] <Grauw> Microformats suck :)
# [12:19] <anne> so does HTML
# [12:19] <anne> (in a way)
# [12:19] <Grauw> ;p
# [12:20] <hsivonen> I want to see markup conformance requirement and consumer processing models for microformats
# [12:20] * sbuluf refrains from showing a big sign calling everyone for revolution (out of scope here)
# [12:20] * Joins: hasather (hasather@81.235.209.174)
# [12:21] <anne> what we're doing might be considered revolution by some people
# [12:22] <sbuluf> anne, compared to the web stalling for years on end, probably is. i meant bigger one, so to speak.
# [12:23] <anne> compared to the XML web vision some people have, I meant
# [12:23] <Grauw> I think the first instinct of many people when something’s not working properly, is to create something new
# [12:24] <Grauw> but creating something new is often not very productive, and involves a big investment
# [12:24] <anne> yeah, see the <q> / <blockquote> -> lets have <quote>! i'm brillaint
# [12:24] <Grauw> (note the implicit reference to <object> and <video> ;p)
# [12:24] <sbuluf> anne, i have seen your ideas about xml, strictness vs. error handling, etc. i'm your opposite, i'm afraid. altough i'd really value to hear more on your reasons.
# [12:25] <anne> Grauw, <object> works completely different from the proposed <video> element
# [12:25] <anne> Grauw, you'd have to add all kinds of attribute and such to it to make it do video in which case you might as well introduce a new element
# [12:26] <sbuluf> grauw, true. and i tried the incremental thing myself, but i saw flaws that...well, were way to big. my feeling was sort of incredulity. example...the whole web editing by hand, then complaining about bad code. solution to bad code, imho, is to have visual, error-prrof editors (other than bugs, of course)
# [12:26] <anne> editors are still written by people
# [12:26] <anne> you can't abstract the problem away like that
# [12:26] <sbuluf> anne, bugs aside, i mean.
# [12:27] <Grauw> I’ll write up a proposal when the list is more stable
# [12:27] <anne> (specs are also written by people, which is another problem)
# [12:27] <anne> Grauw, WHATWG is where <video> happens mostly...
# [12:27] <Grauw> for now, I’ve said enough on the subject on the list already :)
# [12:27] <anne> sbuluf, if you ignore the bugs the design is flawed
# [12:28] <Grauw> The WHATWG is obsolete now :)
# [12:28] <sbuluf> anne, is that your argument against strictness, as opposed to error handling?
# [12:28] <anne> sbuluf, it's one of them
# [12:29] <anne> Grauw, that largely depends on what this WG does
# [12:29] <Grauw> I suppose
# [12:29] <sbuluf> would people not spot bugs, and would not get progrssively fixed?
# [12:29] <anne> and even then I doubt it given that the WHATWG currently has far more members
# [12:29] <anne> sbuluf, yes, meanwhile new features are added introducing more bugs, regressions, etc.
# [12:29] <Dashiva> One web browsers have taught us is that even if you make a better browser, some people will keep using the old ones
# [12:29] <Grauw> so it's going to be a WHATWG vs. HTML WG after all huh
# [12:29] <Dashiva> *One thing
# [12:30] <anne> sbuluf, also, until all bugs are fixed nothing can be deployed because the whole system relies on strictness
# [12:30] <Dashiva> Once a bug is introduced, it's going to stay around for a long time after it's been fixed
# [12:30] <anne> which is kind of the problem
# [12:30] <anne> Grauw, they should just co-exist
# [12:30] <Grauw> I am really having trouble seeing how that works effectively.
# [12:30] <sbuluf> anne, presumably, if nothing works mostly, up to some decent point, nobody would deploy to start with.
# [12:31] <anne> Grauw, give it a few months
# [12:31] * anne doesn't know it either
# [12:31] <Grauw> anne, you’re right.
# [12:31] <Grauw> nobody does.
# [12:31] <anne> sbuluf, right, that would lead to indefinite delay as the stuff you need to support is so complex you'll never get it right the first time
# [12:31] <sbuluf> <anne> sbuluf, yes, meanwhile new features are added introducing more bugs, regressions, etc. <--and what about extra code due to legacy errors, which get perpetuated? more code, more room for bugs
# [12:32] <anne> sbuluf, see all the incremental innovation browsers are doing and how long it takes to get them in line
# [12:32] <Grauw> if there’s multiple implementations of the same spec, even though their may be individual differences and bugs, at least the set described in the spec would be the common one
# [12:32] <anne> sbuluf, legacy code can mostly be described in terms of new features
# [12:33] <Grauw> *there
# [12:33] <sbuluf> anne, but don't you see xml, for example, as an abstraction of some of the p�rsing and handling? stuff we do not need to repeat anymore, and that can be reused?
# [12:33] <anne> sbuluf, for instance, lots of presentational elements can be described in terms of CSS
# [12:33] <hsivonen> Grauw: here's how it could work:
# [12:33] <hsivonen> (disclaimer: no legal statements implied)
# [12:33] <Grauw> problem with HTML was that there’s only been a short time during which there have actually been multiple implementations
# [12:33] <Grauw> (that is, during the time IE and NS were competing, before that it was only NS and after that it was only IE)
# [12:34] <hsivonen> Hixie edits a sigle spec in the WHATWG SVN, creates a WHATWG version every time he commits
# [12:34] <hsivonen> once in a while a W3C snapshot is published under /TR/
# [12:34] <hsivonen> with different headers
# [12:34] <hsivonen> basically the XBL2 model
# [12:34] <sbuluf> grauw, i asked timbl that w3c make a browser. or at least core libraries, that browser vendors coul�d all use. that way, no more loss of synchrony among implementations. unfortunately, he did not answer
# [12:34] <anne> prolly also published on dev.w3.org
# [12:35] <Grauw> the problem is the segmentation of the discussion
# [12:35] <anne> sbuluf, I don't think browser vendors would want that
# [12:35] <hsivonen> Grauw: I expect people who truly care to subscribe to both lists eventually
# [12:36] <Grauw> sbuluf: the W3C doesn’t have the resources to make a browser for all their technologies
# [12:36] <Grauw> plus, there’s Amaya, http://www.w3.org/Amaya/
# [12:36] <anne> and even if they did, it wouldn't support the real world
# [12:36] <hsivonen> Grauw: the WHATWG list can't be obsoleted, because there are people who are barred from subscribing to the HTML WG list
# [12:36] <anne> of which Amaya is the perfect evidence :)
# [12:37] <sbuluf> anne, from a pure efficiency POV...isn't it to have many teams (one per vendor) doing just about the same a crazy thing? also, each gets to be slightly different, driving everyone else crazy...
# [12:37] <Grauw> hsivonen: why would they be barred
# [12:37] <anne> sbuluf, I think it helps driving innovation
# [12:37] <hsivonen> Grauw: if they have a financial relationship with a W3C Member and the AC rep of the Member decides not to nominate them
# [12:37] <sbuluf> grauw, amaya, close, but no cigar, unfortunately. i asked him to make a massively deployable one
# [12:38] <anne> less people working on the same problem likely leads to less innovation
# [12:38] <Grauw> hsivonen, afaik there’s a lot of Mozilla people on the list as ‘invited experts’
# [12:38] <anne> IBM employees for instance
# [12:38] <anne> Y! employees are another example
# [12:38] <sbuluf> anne, right, amaya does not quite make it. but spec makers doing also the core libraries, would solve also the problem of they spitting specs with both hands, while everyopne else tries to implement them
# [12:39] <hsivonen> I know of one IBM employee and one Nokia employee who would like to join but are barred from joining
# [12:39] <Grauw> why can Mozilla people join as invited experts, but IBM and Nokia people not?
# [12:39] <anne> sbuluf, spec writers, implementors and testsuite creators are at best separate persons
# [12:39] <sbuluf> anne, innovation could be, in the form of feedback, concentrated in just one point, instead of dispersed among many different implementations
# [12:39] <anne> Grauw, W3C Patent Policy
# [12:40] <anne> sbuluf, I don't see how that would work
# [12:40] <Grauw> if it’s the patent policy, it’s a good thing that they can’t join then
# [12:40] <sbuluf> anne, which part?
# [12:40] <Grauw> because otherwise everything they suggest might be patented by IBM or Nokia in the future
# [12:40] <anne> "in the form of feedback"
# [12:40] <Grauw> I wouldn’t put it past them either
# [12:41] <Grauw> Both companies have huge patent libraries.
# [12:41] <sbuluf> anne, we all debug just one implementation, that we all use (including opera, mozilla, tec)
# [12:41] <Grauw> sbuluf: it's not going to happen, period.
# [12:41] <hsivonen> Grauw: I guess the answer is one of the following: 1) the invited expert Mozilla people contribute to Mozilla without getting money from a Member or 2) they did not make the required disclosure or 3) the W3C is not applying its policies uniformly
# [12:41] <Grauw> and diversity is good.
# [12:41] <anne> yes
# [12:42] <Grauw> the whole nature of the web is rooted in diversity, and not a sole provider for content/implementations/ontologies.
# [12:44] <sbuluf> graw, take any soft category (picture viewers, for instance). many people started differently, almost all ended up doing, at the end, just about the same. the process converges towards trhe logical features for the task. meantime, however, we, the world, splitted our valuable feedback among scores of people repeating the same thing., if we concentrated feedback on just one, we could debug way faster, no?
# [12:44] <sbuluf> (need to disconnect, will be back in some ten seconds)
# [12:45] <hsivonen> Grauw: I think you are mischaracterizing the effect of the Patent Policy and the implications of IBM or Nokia employees joining
# [12:45] <anne> maybe you should read up about Mozilla and Firefox
# [12:45] <Grauw> hsivonen: the policy is there for a reason.
# [12:45] <anne> I mean, the Mozilla Suite and Firefox
# [12:45] * Joins: pk (udshq@200.49.140.168)
# [12:45] <Grauw> anne, you mean Seamonkey? :)
# [12:45] * pk is now known as sbuluf-
# [12:45] <anne> Grauw, it wasn't called that way back then
# [12:46] <hsivonen> Grauw: yes.
# [12:46] <Grauw> ah, you mean the history.
# [12:46] <anne> only because Firefox started of as a separate project innovation could take place
# [12:46] <anne> it's a pretty good example of why centralizing everything doesn't have to be good
# [12:47] <hsivonen> Grauw: but making the mailing list public and archived is already a partial defense against Nokia and IBM people suggesting something and then proceeding to patent it
# [12:47] <Grauw> there’s not one way to do things.
# [12:47] <sbuluf-> i think it depends how it is done
# [12:47] * Quits: sbuluf (hem@200.49.140.228) (Ping timeout)
# [12:47] <sbuluf-> grauw, if there is real reason for more than one, then more than one implementation is justified.
# [12:47] <Grauw> hsivonen: if it were sufficient, Microsoft (and others I presume) wouldn’t have pressed for having the group at the W3C
# [12:47] <hsivonen> Grauw: the Policy helps with the case where the order of events is the other way round. And it makes your case less expensive to defend against
# [12:48] <hsivonen> Grauw: having all the major players agree to the Patent Policy is good
# [12:48] <anne> Grauw, even Invited Experts have to declare all known patents
# [12:48] <anne> Grauw, so they can't just suggest something their company has patented with themselves knowing about that
# [12:49] <Grauw> anne, yes, that’s exactly what I mean...
# [12:49] <Grauw> hsivonen, IBM is a major player if it comes to software patents :)
# [12:50] <hsivonen> Grauw: but it still makes sense to listen to people who make random comments and have not explicitly agreed to the Policy
# [12:50] <hsivonen> Grauw: it would certainly be good to get IBM to join
# [12:50] <anne> sbuluf-, I think you have to come up with some more substantial evidence than "I think". There's far more evidence supporting a decentralized approach atm.
# [12:51] * Quits: loic (loic@90.29.252.98) (Ping timeout)
# [12:51] <Grauw> sbuluf: it’s simple, if I want to make a web browser I don’t want to be forced to use this ‘base implementation’. There can be several reasons why I wouldn’t want to, e.g. because it doesn’t scale to my needs (either mobile or something bigger), or I just don’t like the way it’s programmed, or I want it in a different programming language, etc.
# [12:51] <Grauw> hsivonen: it would be good to put a little more pressure on them to do so by moving everything to the HTML WG
# [12:52] <sbuluf-> anne, i included "i think" as a form of courtesy, i think =P . talking more seriously, the pattern i mentioned for shareware cemeteries, is pretty easy to see, imho.
# [12:52] <Grauw> or I don’t agree with the license terms
# [12:52] <anne> whatever
# [12:52] * anne grows tired of this silly discussion
# [12:53] * Grauw too
# [12:53] <Grauw> I’m going to get dinner!
# [12:53] <anne> around lunchtime here
# [12:54] * hsivonen wonders what Grauw's PeopleLocation is
# [12:54] <sbuluf-> grauw, otoh, there is the very nature of making standards. if a standard is, by definition, a shared thing...why not to share the core of it's implementation either? browser makers could compite on UI, usability, etc, and still all use the same standard libraries
# [12:54] <hsivonen> oh. Japan
# [12:54] * sbuluf- wonders what was silly about it
# [12:54] <Grauw> I filled it in :)
# [12:55] <Grauw> sbuluf: it’s out of touch with reality
# [12:55] <hsivonen> I though the Netherlands
# [12:55] <Grauw> I’m studying here for a year
# [12:55] <hsivonen> thought
# [12:55] <hsivonen> cool
# [12:55] <Grauw> in august I go back
# [12:55] <Grauw> yup
# [12:56] * anne saw some other people from the HTML WG are NL based
# [12:56] <anne> maybe we should suggest the W3C office in Amsterdam as meeting location? :)
# [12:56] <Grauw> +1
# [12:57] <sbuluf-> grauw, i thought we all assumed a variety of feasability levels. that does not make the conversation silly, imho.
# [12:57] <Grauw> sbuluf, it is if it goes on for lengths :)
# [12:57] <anne> "Uncertainty Reasoning for the World Wide Web Incubator Group Charter" http://www.w3.org/2005/Incubator/urw3/charter
# [12:58] <Grauw> plus, I do not want to offend, but I think in order to argue sensibly on certain topics you should have a little more knowledge of the field
# [12:58] <sbuluf-> sbuluf, "i'm tired, enough for now" would not do, without implying sillyness?
# [12:59] <sbuluf-> i see. i wonder which part on my side was so out of place.
# [13:00] * Joins: alexf (alejandro@85.152.42.1)
# [13:00] <sbuluf-> )rethoric question, no need to answer if tired, of course)
# [13:00] <alexf> hello everybody
# [13:00] <sbuluf-> hi
# [13:01] <hsivonen> anne: interesting
# [13:03] <anne> yeah
# [13:05] * MikeSmith (seeing anne's comment about reading up on Firefox and Mozilla) wonders how many people know/remember where what became Firefox came from (who was the driving force behind it)
# [13:06] * Joins: loic (loic@90.29.147.122)
# [13:06] <MikeSmith> hsivonen - why do you say the person you know from Nokia is blocked from joining?
# [13:08] <Grauw> mike, it’s not *that* long ago :)
# [13:08] <hsivonen> MikeSmith: I noticed that a Nokia-employee tried to follow the instructions for joining as a public invited expert but noticed that the process was not meant for employees of Members. and so far, no one has joined as a Nokia rep.
# [13:09] <MikeSmith> Grauw - long enough ago that some people don't seem to actually know who it was
# [13:10] <MikeSmith> hsivonen - OK. I thought that you were saying that Nokia had some reason for not joining.
# [13:12] <anne> MikeSmith, who was it?
# [13:12] <MikeSmith> anne - you tell me
# [13:12] <hsivonen> MikeSmith: I meant that the W3C blocks employees of Members from routing around the AC rep and it appears that at least for the time being the Nokia AC rep has not unblocked Nokia employees.
# [13:12] <anne> dhyatt and someone else who left the Mozilla project now iirc
# [13:12] <anne> who both*
# [13:13] <MikeSmith> the someone else is still with Mozilla, as far as I know
# [13:13] <hasather> Blake Ross?
# [13:13] <MikeSmith> yeah
# [13:14] * Joins: zcorpan_ (zcorpan@84.216.43.95)
# [13:18] <sbuluf-> later, everyone
# [13:20] <MikeSmith> anne - more than a few people I have talked with -- including people who know about dhyatt's work on Safari -- don't seem to know that he was involved with Firefox at al
# [13:21] * Quits: sbuluf- (udshq@200.49.140.168) (Ping timeout)
# [13:21] <anne> I don't think he cares much for fame
# [13:23] <MikeSmith> yeah, I guess not
# [13:26] <MikeSmith> I just wonder sometimes how many people realize that much that creation and characteristics of the applications they use have come from real people, not from, well, corporate marketing departments
# [13:27] * Parts: alexf (alejandro@85.152.42.1)
# [13:28] * Joins: Philip (excors@80.177.163.133)
# [13:35] <anne> woha, 20 events for HTMLMediaElement
# [13:55] <Grauw> got a link, anne?
# [13:56] <anne> #media
# [13:58] <Grauw> well events are usually easy to implement
# [13:58] <Grauw> just create an event object at the proper location
# [14:00] <anne> i'm not opposed
# [14:00] <Grauw> events nice :)
# [14:02] <Grauw> why doesn’t it enforce OGG Vorbis support, btw, only wave...
# [14:03] <Grauw> for <audio>, that is
# [14:03] <Grauw> anyway, I’m seeing a significant overlap between <audio> and <video>, and e.g. why there’s a "Which frame in a video stream corresponds to a particular playback position is defined by the video stream's format." note for video but not for audio I don’t really understand
# [14:04] <anne> someone said because it was enforced for <video>
# [14:05] <Grauw> basically, a lot of arguments against <object> (because of the supposed complexity of having different media types on one element) apply to the current phrasing in the spec as well
# [14:05] <Grauw> *current definition
# [14:07] <anne> Nokia just joined the WG
# [14:07] <zcorpan_> ms still missing?
# [14:07] <Grauw> that’s great news.
# [14:07] <anne> Mikka Honkala is their guy.
# [14:08] <anne> zcorpan_, yes
# [14:09] <anne> Grauw, you mean because the common things between video and audio have been abstracted into a single interface?
# [14:13] <MikeSmith> anne - I don't know Mikka Honkala yet. Do you know if he works on the S60 browser?
# [14:13] <anne> he worked on X-Smiles iirc
# [14:14] <anne> http://hsivonen.iki.fi/honkala-xforms/ has some info
# [14:14] <hsivonen> Mikko Honkala was one of the main developers of the XForms functionality for X-Smiles
# [14:14] <MikeSmith> aha
# [14:15] <hsivonen> my understanding is that in January he was involved with some Nokia-internal XForms stuff. The S60 browser team showed up at his thesis defence, though.
# [14:15] <anne> From the excerpts on that page he seems like a sensible guy
# [14:16] <MikeSmith> and he's a bonfied implementor/developer, I guess
# [14:16] <MikeSmith> bonified
# [14:17] <MikeSmith> and regardless of what you might think of XForms, you kinda gotta admire somebody who's implemented it
# [14:18] <MikeSmith> the work of implementing it
# [14:19] <anne> Like I said, he seems like a sensible guy
# [14:19] <Grauw> anne, there’s hardly anything ‘uncommon’ left.
# [14:20] <anne> default presentation
# [14:20] <Grauw> mike, I think you were looking for is ‘bona fide’
# [14:20] <anne> contextmenu
# [14:21] <Grauw> anne, for mp3s with cover art in them, it shouldn’t show anything?
# [14:21] <anne> <audio>?
# [14:21] <Grauw> yes
# [14:21] <anne> dunno
# [14:22] <Grauw> well the current spec certainly prevents it from doing that if it says audio is not shown
# [14:22] <Grauw> and it’s not <video> either, so if a browser wants to do that, he’s proably going to create a new <audio-coverart> element
# [14:22] <Grauw> :)
# [14:23] <anne> or just <audio> + <img>
# [14:23] <Grauw> it’s embedded in many MP3s...
# [14:23] <anne> yeah, dunno what you'd want to do with it
# [14:24] <anne> how DVD like stuff would work is not entirely clear to me either for instance
# [14:24] <anne> the default presentation of <video> is pretty clear to me (without controls set)
# [14:24] <anne> with controls set i'm not so sure anymore
# [14:25] <anne> dunno about <audio>... display:none?
# [14:26] <Grauw> display should indeed be handled by CSS
# [14:26] <Grauw> audio without cover art will just get a (0,0) size
# [14:26] <Grauw> also, what about chapters. can you do <audio src="playlist.m3u">, etc, I think that’s useful
# [14:26] <MikeSmith> anne - yeah, geez, "bona fide"
# [14:26] * MikeSmith thinks the longer I'm in Japan the worse my English is getting
# [14:27] <anne> Grauw, you want to know upfront what the UI will be
# [14:27] <anne> as an author
# [14:27] * Grauw at international student house, so I talk more English than Japanese ;p
# [14:27] <MikeSmith> ボナファイド
# [14:27] <Grauw> they say that? :)
# [14:28] <Dashiva> More like pronounce it like that, I'm guessing
# [14:28] <MikeSmith> Grauw - somebody probably does
# [14:28] <Grauw> mike, ;p
# [14:28] <Grauw> anne, actually, I think it should default to having UI, be <object> (of course), and have an attribute/parameter that says noui="noui" or something with a better name
# [14:29] <Grauw> by the way, you don’t know the size of a <video> in advance either
# [14:30] <Grauw> mike, my dictionary says they say 誠実に :)
# [14:31] <anne> Grauw, you do
# [14:31] <Grauw> (せいじつに)
# [14:31] <anne> it's a replaced element so the default size will be 300*150 unless you specify something else through CSS
# [14:31] <Grauw> it doesn’t size to the video’s size by default?
# [14:31] <Grauw> ugh
# [14:31] <anne> the video size scales inside the frame created by CSS
# [14:31] * anne likes that approach
# [14:32] <MikeSmith> Grauw - I think probably you mean 誠実な
# [14:32] <Grauw> yes of course it scales :)
# [14:32] <Grauw> it says 誠実に adv. (Hira=せいじつに) faithfully, truly 誠実な adj. (Hira=せいじつな) faithful, credible
# [14:33] <Grauw> and bona fide only mentions the first
# [14:33] <Grauw> other than that, I know nothing, my Japanese is still terrible :)
# [14:33] <anne> "Video content should be rendered inside the element's playback area such that the video content is shown centered in the playback area at the largest possible size that fits completely within it, with the video content's aspect ratio being preserved. Thus, if the aspect ratio of the playback area does not match the aspect ratio of the video, the video will be shown letterboxed. Areas of the element's playback area that do not contain the video
# [14:33] <anne> should be filled with pure black."
# [14:33] <Grauw> well I dislike it
# [14:34] <Grauw> <img> doesn’t have a default size either
# [14:34] <anne> it does
# [14:34] <anne> 300*150
# [14:34] <Grauw> yet nobody complains about the image size being unpredictable
# [14:34] * Joins: barstow (ce846302@128.30.52.23)
# [14:34] <hsivonen> Grauw: would you rather have the UA fetch the poster frame of the video before committing to the box size?
# [14:34] <anne> but it fall back to the intrinsic size of the image
# [14:34] <Grauw> anne, ke?
# [14:34] <anne> falls*
# [14:34] <Grauw> hsivonen: I want it to work like <img>
# [14:34] <anne> for instance, <img> loading SVG might fallback to 300*150
# [14:35] <Grauw> if you don’t want ugly reflows, just specify a size
# [14:35] <hsivonen> anne: where did those dimensions come from? is that what Opera/Gecko/WebKit implment?
# [14:35] <anne> hsivonen, that's what the defacto behavior is for <iframe> and therefore that's what CSS 2.1 specifies
# [14:36] <Grauw> a non-loaded <img> or an <img> that failed loading is certainly not 300x150
# [14:36] <hsivonen> anne: ok. there's so much stuff to learn
# [14:36] <anne> Grauw, in that case it no longer is a replaced element
# [14:36] <anne> Grauw, just a simple inline element
# [14:36] <Grauw> at the point before it is loaded?
# [14:37] * anne isn't entirely sure about that
# [14:37] <Grauw> well, it’s not in current implementations.
# [14:37] <anne> hsivonen, yeah, CSS is fricking complex
# [14:38] <anne> it's not what? (note that I'm not sure what the behavior should be in that case)
# [14:38] <anne> well, failed loading is clear
# [14:38] <anne> loading is not
# [14:39] <Grauw> if an image tag does not specify a size by means of the width and height attributes or CSS, the default size it occupies is either 0 or the size of a broken-image icon, I think
# [14:39] <hsivonen> AOL has joined, too
# [14:39] <anne> yeah, some time ago
# [14:40] <anne> well, March 28
# [14:41] <Grauw> anyway, I’m going to update my BIOS, and then retire for the evening
# [14:41] * Quits: Grauw (ask@202.71.92.74) (Quit: I bid y’all goodbye!)
# [14:48] * Joins: Lachy_ (Lachlan@124.168.25.222)
# [14:51] * Quits: Lachy (Lachlan@203.214.144.160) (Ping timeout)
# [15:05] <MikeSmith> anne - does the Wep Apps 1.0 spec cover something related to delayed script execution?
# [15:06] <Dashiva> it specifies defer and async properties
# [15:06] <MikeSmith> Dashiva - OK
# [15:06] * MikeSmith wonders what the origins of the spec for those is
# [15:08] <anne> async is new
# [15:08] <anne> defer is IE
# [15:08] <anne> iirc
# [15:08] <MikeSmith> what use case is behind the defer and async attributes?
# [15:09] <MikeSmith> and are the use cases documented anywhere? (the wiki?)
# [15:09] <anne> not delaying the parser
# [15:09] <anne> no, feel free to document usecases
# [15:09] <anne> WHATWG lacks such an effort atm
# [15:09] <anne> they're mostly documented on the list
# [15:11] <MikeSmith> anne - and what advantage is there to not delaying the parser? I mean in what cases is it more important/useful to not delay the parser?
# [15:11] <anne> "There are three possible modes that can be selected using these attributes. If the defer attribute is present, then the script is executed when the page has finished parsing. If the defer attribute is not present but the async attribute is present, then the script will be executed asynchronously, as soon as it is available. If neither attribute is present, then the script is downloaded and executed immediately, before the user agent continues
# [15:11] <anne> parsing the page. The exact processing details for these attributes is described below."
# [15:12] <anne> I'm not entirely sure what the use case for async is, but defer is prolly to show the content first
# [15:12] <MikeSmith> yeah
# [15:12] <anne> oh actually
# [15:12] <anne> async helps with that too
# [15:12] <Dashiva> async is useful for library scripts and the such
# [15:13] <anne> nm my last remark
# [15:13] <anne> what does async help with in that case Dashiva?
# [15:13] <MikeSmith> Are there implementations already?
# [15:13] <Dashiva> They don't hold up the page parsing when downloading
# [15:13] <anne> IE implements defer
# [15:14] <anne> Dashiva, why not use defer?
# [15:14] <anne> but what IE does is different from the spec it seems
# [15:14] <Dashiva> There's no need to limit it to after page load
# [15:15] <MikeSmith> I think mobile browser (or browsers on "constrained devices") are an obvious use case for this.
# [15:15] <anne> that sounds like an argument to remove the feature MikeSmith :)
# [15:16] <MikeSmith> anne - ?
# [15:16] <anne> authors shouldn't be encouraged to create device specific pages
# [15:16] <MikeSmith> true
# [15:16] <MikeSmith> perhaps
# [15:16] <MikeSmith> or perhaps not
# [15:16] <MikeSmith> depending on who you talk to
# [15:17] <MikeSmith> anyway, I think it can create implementation issues and bugs because of complexities with CSS interaction
# [15:17] <MikeSmith> maybe
# [15:18] <Dashiva> One of the open issues with async is that you don't know if the script will run before or after load
# [15:18] <MikeSmith> but I guess that's neither here not there
# [15:26] <anne> i have no idea how it will effect CSS actually
# [15:35] * Quits: barstow (ce846302@128.30.52.23) (Quit: CGI:IRC (EOF))
# [15:45] * Joins: asbjornu (asbjorn@84.48.116.134)
# [16:13] * Joins: alexf (alejandro@85.152.42.1)
# [16:28] * Joins: glazou (daniel@80.118.184.70)
# [16:28] <glazou> hello
# [16:28] <glazou> anne: ping
# [16:28] <anne> pong
# [16:28] <anne> and hi!
# [16:29] <glazou> anne: hi ; suppose you have a document with CSS styles for 'projection' medium. Should a browser fullscreen mode automatically enable them or ask the user and what does Opera about it ?
# [16:29] <anne> opera automatically applies projection in F11
# [16:30] <glazou> hmmm
# [16:30] <glazou> is opera the only browser enabling projection medium ATM ?
# [16:30] <anne> There've been some ideas floating around of making a "complicated" UI but I don't think anybody got around doing that
# [16:30] <anne> glazou, yes
# [16:30] <glazou> thanks anne
# [16:30] <glazou> anne: see my blog, last post
# [16:30] <glazou> firefox
# [16:32] <anne> cool
# [16:32] * glazou needs to read about opera slides
# [16:32] <glazou> do you happen to have a url about it handy ?
# [16:33] <glazou> opera show
# [16:33] <anne> http://www.opera.com/support/tutorials/operashow/
# [16:33] <anne> maybe?
# [16:33] <glazou> thx
# [16:35] <glazou> oh so it's based purely on css-generated page breaks, very cool
# [16:35] <anne> yeah
# [16:35] <anne> we call it "Opera Show" but it's just CSS :)
# [16:35] * glazou going to beat it
# [16:36] <glazou> :)
# [16:36] <hsivonen> glazou: have you got projection page breaks working in Gecko?
# [16:36] <glazou> no
# [16:36] <glazou> well not yet
# [16:37] <hsivonen> having those would be awesome
# [16:37] <glazou> but that's not really an issue
# [16:37] <glazou> yes
# [16:37] <glazou> would help, but again, I know how to do "Firefox Show" without
# [16:38] <glazou> in fact Opera show is not really a slideshow system, it's only a paginated mode w/o scrollbar
# [16:38] <glazou> I'll do a real slideshow system
# [16:38] <hsivonen> what do you mean by "real" compared to Opera?
# [16:39] <glazou> where a slide can contain transitions between components ? render one LI at a time ?
# [16:39] <hsivonen> I see
# [16:39] <anne> implementing css3-preslev ?
# [16:39] <anne> ( http://www.w3.org/TR/css3-preslev/ )
# [16:40] <glazou> not yet, but thinking about it, yes
# [16:54] * Yudai is now known as colon_equal
# [17:04] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Get thee behind me, satan.)
# [17:14] * Quits: glazou (daniel@80.118.184.70) (Quit: away)
# [17:17] * colon_equal is now known as Yudai
# [17:18] * Joins: h3h (bfults@66.162.32.234)
# [17:19] * Quits: anne (annevk@81.68.67.12) (Ping timeout)
# [17:53] * Quits: edas (edaspet@88.191.34.123) (Quit: http://eric.daspet.name/ et l'édition 2007 de http://www.paris-web.fr/ )
# [18:01] * Parts: alexf (alejandro@85.152.42.1)
# [18:01] * Joins: anne (annevk@86.90.70.28)
# [18:56] * Joins: tylerr (tylerr@66.195.32.2)
# [18:57] <tylerr> Good day all.
# [18:57] * Joins: myakura (myakura@60.239.122.32)
# [19:03] <zcorpan_> g'day
# [19:04] <anne> it certainly is here
# [19:05] * Joins: hober (ted@66.162.32.234)
# [19:06] <zcorpan_> anne: what is?
# [19:06] * Joins: dbaron (dbaron@63.245.220.242)
# [19:07] <anne> a good day
# [19:07] <zcorpan_> ah
# [19:08] <tylerr> Ah hello anne. How did the discussion wrap up earlier?
# [19:09] <anne> subject was?
# [19:10] <tylerr> All the tag talk about 's and <image> and whatnot.
# [19:14] <tylerr> When I left it was a rather interesting discussion.
# [19:15] <tylerr> Then again, all the discussions on here are rather interesting. :-)
# [19:16] * Parts: hasather (hasather@81.235.209.174)
# [19:21] * Joins: st (st@62.234.155.214)
# [19:38] * Joins: kingryan (kingryan@66.92.187.33)
# [19:42] * Quits: Shunsuke (kuruma@219.110.80.235) (Ping timeout)
# [20:12] <anne> Microsoft joined
# [20:12] <anne> Chris Wilson is their only participant so far
# [20:12] <zcorpan_> finally!
# [20:13] <h3h> hooray
# [20:13] <Dashiva> huzzah
# [20:13] <hsivonen> hooray!
# [20:13] <hsivonen> http://lists.w3.org/Archives/Public/www-forms/2007Apr/0006.html
# [20:14] <anne> http://www.w3.org/mid/5C276AFCCD083E4F94BD5C2DA883F05A27946E6FA5@tk5-exmlt-w600.wingroup.windeploy.ntdev.microsoft.com
# [20:17] * Joins: hasather (hasather@81.235.209.174)
# [20:20] <tylerr> Woo.
# [20:21] <anne> hsivonen, seems like versioning for the sake of it
# [20:21] <anne> not really thought through
# [20:22] <zcorpan_> versioning is the killer feature
# [20:22] <zcorpan_> :)
# [20:23] <Dashiva> Next we'll be versioning language in school
# [20:23] <Dashiva> <report version="2007-urban-slang">
# [20:23] <zcorpan_> perhaps language tags should have a version parameter
# [20:24] <zcorpan_> lang="en-GB;version=2.0"
# [20:24] <anne> perhaps element names should have a version parameter
# [20:24] <anne> <tag;2>
# [20:24] <Dashiva> A version parameter in img would work for adding fallback :)
# [20:25] <zcorpan_> that would be so cool
# [20:25] <anne> can't believe nobody thought of that!
# [20:25] <DanC> From: Chris Wilson <Chris.Wilson@microsoft.com>
# [20:25] <DanC> To: public-html@w3.org <public-html@w3.org>
# [20:25] <DanC> Subject: Microsoft has now joined the HTML Working Group
# [20:25] <DanC> Date: Wed, 4 Apr 2007 11:15:50 -0700 (13:15 CDT)
# [20:25] * Parts: asbjornu (asbjorn@84.48.116.134)
# [20:25] <anne> DanC, see above :)
# [20:25] * DanC is late to the party again. oh weel.
# [20:25] <Dashiva> So, what's the first post on the program now?
# [20:26] <anne> your announcement prolly wins in geekiness
# [20:26] <DanC> the list of issues I'm swapped in on is still http://www.w3.org/html/wg/il16
# [20:26] <DanC> I haven't even read Chris W's msg yet. and I have another appointment just nwo.
# [20:27] <DanC> it's with my typing tutor.
# [20:27] <DanC> ;-)
# [20:27] <hsivonen> DanC: will the WG now proceed to discuss the issue whether to take the HTML5+Hixie package? or are we still waiting for e.g. IBM or Adobe to join?
# [20:27] <anne> woha, Chris wants versioning
# [20:27] <DanC> the WG has been discussing that for a while; the question is when we'll stop discussing and call the question
# [20:27] * anne ponders about the role of a co-chair
# [20:28] <hsivonen> anne: whoa about versioning indeed
# [20:29] <Dashiva> Technically, as long as we have backwards compatability as a leading star, shouldn't every document should be eligible for validation/conformance checking based on the latest standard?
# [20:29] <hsivonen> Dashiva: yes
# [20:29] <hsivonen> Dashiva: but HTML5 does break conformance compat with HTML 4
# [20:30] <hsivonen> Dashiva: basically %Flow becomes bimorphic
# [20:31] <Dashiva> Will that invalidate pages?
# [20:31] <hsivonen> Dashiva: yes
# [20:32] <tylerr> So are we talking about an agile method of moving HTML forward, with the "release early, release often" mentality? I mean, release HTML 4.1 then a few months later have 4.2 come out? I'm a bit unclear about the versioning.
# [20:33] <Dashiva> Well, some browsers are implementing parts of HTML5 even now, so you could say they are at various stages of HTML 4.x
# [20:34] <Dashiva> But it's not a well-defined progression of features, just pick-and-choose
# [20:34] <tylerr> Sure, it's like a grab-bag at this point.
# [20:34] <Philip> Dashiva: It sounds like there's a difference between versioning for conformance checking, and versioning to implement "don't break the web" like in quirks/standards mode - in the latter case, you can't really add new features without breaking existing pages (when they happen to (invalidly, mistakenly) use the new tag name)
# [20:35] <gavin_> anne, hsivonen: his email makes it sound like he's talking about versinoing the spec, not versioning documents
# [20:35] <anne> tylerr, not just at this point
# [20:35] <Dashiva> Philip: I think there's an implicit "don't break [more than 0.001% of] the web"
# [20:35] <anne> tylerr, on the web incremental evolution is sort of a constant
# [20:35] <zcorpan_> gavin_: that's how i read it too
# [20:36] <gavin_> anne: (given the quoted message he's replying to)
# [20:36] <tylerr> anne: Oh sure! I'm just wondering then what Chris means by versioning.
# [20:36] <anne> hmm, ok
# [20:36] * hsivonen is eagerly waiting to see what Chris replies to the messages about adopting the XBL2 spec editing model
# [20:36] <anne> then I'm confused as to why he mentioned Firefox development cycles
# [20:37] * zcorpan_ too
# [20:37] <tylerr> So then do we have a HTML 4.1 that only adds new elements, keeps all the current ones, then slowly start to depricate while introducing replacements?
# [20:37] <gavin_> anne: as an example of why giving the spec a verisino would be useful, I'm guessing
# [20:37] <gavin_> i.e. the ability to say "Firefox X supports HTML Y"
# [20:37] <anne> tylerr, introducing replacements?
# [20:38] <anne> tylerr, we're fixing the web here, not replacing it
# [20:38] * tylerr chuckles.
# [20:38] <Philip> Dashiva: That seems reasonable for the latter case. The former (versioning for conformance checking) seems to be of less practical relevance, given that most HTML4 pages aren't valid, so it doesn't matter whether they'll be valid HTML5 or not
# [20:39] <tylerr> I should have worded it as "fixes" then. Replacement does have a feeling of finality to it anne. :-)
# [20:39] <Philip> and I'd guess (with no reasonable basis) Chris was talking about the don't-break-existing-invalid-pages versioning, so the arguments about versioning for conformance checking are not as relevant
# [20:39] <tylerr> Sure.
# [20:39] <anne> 95% of the HTML pages are syntactically incorrect. I doubt as much as a percent is actually conforming.
# [20:39] <Philip> Which may all be obvious and/or wrong, but I was just trying to work out what I was thinking of :-)
# [20:40] <tylerr> anne: We can blame that on WYSIWYG. :-)
# [20:40] <tylerr> And poor editors.
# [20:41] <anne> and hand authoring
# [20:41] <zcorpan_> and misguided tutorials
# [20:41] <anne> basically, we can blame the people
# [20:41] <Dashiva> anne: Well, after the half a million test cases we have to write, it'll be a bit closer to one percent at least :)
# [20:42] <zcorpan_> lol
# [20:42] * anne almost never writes conforming testcase documents
# [20:42] <zcorpan_> you'd have to write a billion test cases to come closer to 1%
# [20:42] * Joins: mjs (mjs@64.81.48.145)
# [20:47] <Philip> I've found the best way to create lots of test cases is to write a program which runs through every combination of multiple inputs and generates a test case for each. Thanks to the power of combinatorics, you can just add a couple more inputs each time the web gets an order of magnitude larger, in order to keep up.
# [20:50] * anne writes them by hand mostly so he can easily tweak them
# [20:52] <mjs> the tool will rarely be able to predict the correct output for each test case though
# [20:53] <anne> we did make a specialized format for the parsing testcases
# [20:53] <anne> where "we" is Hixie who contributed it
# [20:53] <Philip> If the spec is sufficiently detailed and inflexible, you could write a perfect reference implementation and use that to calculate the correct output
# [20:54] <anne> http://html5lib.googlecode.com/svn/trunk/tests/tree-construction/tests1.dat
# [20:54] <anne> etc.
# [20:54] <Philip> and once you have one small part of the spec which is like that, you can make a billion test cases for that area :-)
# [20:55] <Philip> (But it's not so good for covering the rest of the spec where it's fluffier, I guess)
# [20:55] <anne> the spec shouldn't be "fluffy"
# [20:55] <anne> except maybe about semantics, which you can't really test anyway
# [20:56] <anne> Microsoft also nominated Miller Abel
# [20:56] <zcorpan_> Philip: the problem is the reference implementation would most likely also have bugs :)
# [20:57] <kingryan> Philip: there's no way to assert that a reference implementation is complete and bug free without a test suite (IMO)
# [20:58] <anne> (a test suite can also contains bugs, fwiw)
# [20:58] <anne> we should now have a circle
# [20:58] <mjs> XPointer as an alternative to BLOCKQUOTE, what a great idea
# [20:58] <zcorpan_> and a spec can contain bugs...
# [20:58] <anne> right, we missed that one :)
# [20:59] <anne> mjs, there's something about X that solves all your problems
# [20:59] <mjs> Philip: if it were that easy to write a perfect reference implementation of the spec, there would be no need for a test suite
# [21:01] <mjs> ooh, Chris Wilson is on the list, I'd better hurry
# [21:01] <Philip> anne: Hmm, I suppose all the "should" statements could be considered fluffy - but WA1 has far more "must"s than "should"s, so actually it seems like a lot can be relatively easily tested
# [21:02] <anne> Philip, all the authoring should are fluffy, but they're related to authoring so can be safely ignored unless you're making testcases for a conformance checker
# [21:02] <anne> Philip, UA SHOULD requirements are mostly things related to network access and security iirc
# [21:02] <anne> of which you can safely test the latter
# [21:04] <anne> "274 group participants"
# [21:09] <Philip> I noticed http://www.w3.org/TR/grddl/ has mechanical rules - if they were normative, and if the language they're written in has formally defined semantics, then the spec would effectively be the reference implementation, and it would be perfectly self-consistent, and you could define away any bugs because they're really just features
# [21:09] <Philip> then a test suite would still be useful to compare the output from optimised implementations
# [21:10] <Philip> But that's sounding like crazy formal semantics that doesn't really scale to work in the real world :-)
# [21:11] <anne> if you invent some script that deals en-GB-x-Hixie it might
# [21:11] <anne> deals with*
# [21:25] <mjs> is it just me, or is Chris Wilson's mail client sending things in weird fonts?
# [21:25] <anne> Comic Sans?
# [21:25] * anne only receives HTML e-mail
# [21:25] <anne> euh, text e-mail*
# [21:27] <hsivonen> I'm getting what looks like Courier New in Mail.app
# [21:28] <hsivonen> the last message that is
# [21:28] <hsivonen> the earlier ones looked normal
# [21:29] * DanC is away: eye Dr. etc.
# [21:31] * Quits: heycam (cam@203.214.79.176) (Ping timeout)
# [21:46] * anne just hears he's free to do something besides work tomorrow, the day after and Monday!
# [21:48] * Joins: heycam (cam@203.214.79.176)
# [21:48] <hsivonen> is Maundy Thursday a non-work day in Norway?
# [21:48] <anne> for Opera, it is
# [21:48] <mjs> hsivonen: two of his messages came out in a funny font (the most recent was Courier New and the text didn't wrap)
# [21:49] <Hixie> mmm, microsoft wants versioning
# [21:49] <mjs> Chris Wilson asked for it, but I'm not sure he's read through the discussions that led to a conclusion of no versioning
# [21:50] <mjs> I thought versioning was a good idea too when less informed
# [21:50] <Hixie> sadly, he's our chair, so it might be necessary to convince him
# [21:51] <Hixie> i like the way people assume that "content sniffing" is a single feature
# [21:51] <Dashiva> Did you see the rumor about you in #whatwg, Hixie?
# [21:51] <Hixie> as opposed to a different one for each time it happens, in <img>, in <style>, in <script>, in a browsing context, in an <object>, when downloading, etc
# [21:52] <Hixie> Dashiva: rumous?
# [21:52] <Hixie> rumour, even?
# [21:52] <Dashiva> * Dorward hears a rumour that Hixie is pushing for clients to be allowed to treat text/plain documents as HTML and points out that when Safari did that to http://www.hixie.ch/advocacy/xhtml it became rather difficult to read.
# [21:52] <Hixie> given that the html5 spec right now specifically disallows treating text/plain as text/html...
# [21:52] <mjs> I think Hixie specifically didn't push for that
# [21:53] <mjs> it's true that content sniffing is different in different cases
# [21:53] <Dashiva> Yeah, I think it's a misunderstanding based on image/* sniffing. But rumors rarely care about fact
# [21:53] <mjs> binary formats are unambiguously self-describing, so being strict about the type for those is of dubious value
# [21:54] <anne> especially since authors get it wrong
# [21:54] <Hixie> some binary formats are unambiguously self-describing
# [21:54] <Hixie> not all
# [21:54] <mjs> s/are/are often/
# [21:54] <Hixie> yeah
# [21:54] <Hixie> some text formats are too
# [21:54] <Hixie> PDF, e.g.
# [21:54] <Hixie> er
# [21:54] <Hixie> PS, rather
# [21:55] <anne> am I posting in the past or are other people posting in the future?
# [21:55] <Hixie> JPEG/JFIF is hard to detect, you only really have three bytes to go on
# [21:56] <mjs> is it feasible to do a study of how many text/plain documents there are on the web that appear to be HTML by sniffing, and whether it appears those expect to be rendered as HTML or plain text?
# [21:56] <mjs> I honestly don't know
# [21:56] <mjs> we added the sniffing for that to Safari a long time ago when we found some sites that broke if you treated plain text strictly, but I don't know what those were and whether that is still common, and now we are scared to change it
# [21:57] <anne> IE doesn't seem to trigger HTML rendering mode for http://www.hixie.ch/advocacy/xhtml
# [21:57] <anne> HTML parsing, even
# [21:57] <Hixie> i can tell you how many text/plain documents google thinks are html, but that tells you more about google than text/plain or HTML
# [21:57] <Hixie> IE can be tricked into treating text/plain as HTML
# [21:57] <Hixie> it just takes more than the xhtml page
# [21:58] <mjs> it would probably require some individual inspection of some of those pages to determine author intent
# [21:58] <Hixie> http://www.hixie.ch/tests/adhoc/http/content-type/014.html e.g.
# [21:58] <Hixie> mjs: yeah
# [21:58] <mjs> but knowing number and surveying a subset by hand would be useful, at least to me
# [21:58] <Hixie> mjs: firefox never treats text/plain as HTML and has to my knowledge never had much of a problem with it
# [21:58] <Hixie> mjs: text/plain has to be sniffed for binary content, though, and the HTML5 spec says how to do that
# [21:59] <Hixie> mjs: remind me when i'm in the office
# [22:00] <mjs> Hixie: I'm not particularly resolute against changing it, but it's very hard for me to get the data to justify it myself; Firefox not doing it is a fairly strong point
# [22:00] <mjs> we also do sniffing for RSS, but not sure if that is directly relevant to the HTML spec
# [22:01] <anne> I think that's covered
# [22:01] <anne> Opera doesn't seem to treat 014.html as HTML either
# [22:01] <mjs> It's pretty much impossible to find an RSS feed with a MIME type of application/rss+xml or application/x-rss+xml or whatever
# [22:01] <Hixie> mjs: sniffing for RSS is already required by HTML5 :-)
# [22:02] <Hixie> http://www.whatwg.org/specs/web-apps/current-work/#content-type3
# [22:02] <anne> http://www.whatwg.org/specs/web-apps/current-work/#content-type-sniffing
# [22:05] <Hixie> the warning given at the top of that section is not hypothetical, btw
# [22:05] <Hixie> it is possible to trick IE into thinking certain files are HTML, which is actually an XSS hole in many, many web sites
# [22:05] <Hixie> today
# [22:06] <mjs> our security guys have raised issues about sniffing for html in text/plain before
# [22:08] <gavin_> I don't think "Microsoft wants versining" is the right conlusion to make given Chris' email
# [22:08] <gavin_> it looks to me like there's confusion as to what "versining" means
# [22:08] * gavin_ wonders how he managed to typo "versioning" twice
# [22:08] <tylerr> I'd say there is some clarification needed.
# [22:08] <Dashiva> Now there's confusing about versining too
# [22:08] <tylerr> gavin_: Improper versioning. ;-)
# [22:09] <gavin_> the email he was replying to was talking about giving the spec a version
# [22:09] <gavin_> not about requiring that documents indicate their versions
# [22:09] <hsivonen> the spec has an SVN revision id. :-)
# [22:09] <anne> yet he also mentioned he disagreed with the design principle
# [22:11] <gavin_> maybe he just disagrees with what he believes it the design principle after reading the unrealted talk about what to call the spec :)
# [22:11] <gavin_> I hope so, anyways
# [22:11] * gavin_ hopes people will forgive his SSH-lag induced typos
# [22:12] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
# [22:13] <Philip> I thought there was some discussion a while ago (in "Using the HTML5 DOCTYPE as a new quirksmode switch") when he had asked for something that sounds (to me) like a form of document versioning
# [22:14] <Philip> (so I assume the discussion there, rather than on the HTML WG list, is more relevant)
# [22:28] * Quits: loic (loic@90.29.147.122) (Quit: hoopa rules)
# [22:29] * Joins: asbjornu (asbjorn@84.48.116.134)
# [22:36] * Quits: heycam (cam@203.214.79.176) (Ping timeout)
# [22:42] * h3h wishes Chris Wilson would send email as plaintext. that MS Word MIME stuff is horrid
# [22:43] * hober should really get around to figuring out how to tell gmail to prefer text/plain alternatives
# [22:43] <tylerr> That's Outlook for you h3h. :-(
# [22:43] <h3h> You can even tell Outlook to use plain text
# [22:44] * Parts: asbjornu (asbjorn@84.48.116.134)
# [22:46] * anne only receives text in Opera
# [22:58] * zcorpan_ would prefer text for emails, but html for feeds. unfortunately opera has the same setting for both at the same time
# [22:58] * anne uses bloglines.com for feeds atm
# [22:59] <zcorpan_> opera is by far the best feed reader i've used
# [23:01] <tylerr> I enjoy Google Reader, but that's because I haven't tried Opera's.
# [23:04] <zcorpan_> to read feeds, all i have to do is keep hitting space. pretty much like email. very convenient
# [23:06] <hasather> zcorpan_: same in Google Reader too. I use that so that I can read feeds on different devices
# [23:07] <zcorpan_> ok
# [23:10] <tylerr> How does Reader do on mobiles?
# [23:10] <hasather> there is a mobile version
# [23:11] <hasather> http://reader.google.com/m
# [23:11] <tylerr> Ah well, that would help if I searched beyond my own nose. :-)
# [23:11] <tylerr> Thanks.
# [23:11] <hasather> no, hmm, was that really it?
# [23:12] <tylerr> Oh wait, that's Google's search page it seems.
# [23:12] <hasather> http://www.google.com/reader/m/view/
# [23:12] <hasather> there it is
# [23:12] <tylerr> Ah brilliant!
# [23:21] * Joins: heycam (cam@203.214.79.176)
# [23:23] * DanC is away: done for the day
# [23:36] * Joins: mw (chatzilla@84.41.169.151)
# [23:40] * Quits: mw (chatzilla@84.41.169.151) (Quit: Chatzilla 0.9.75.1 [SeaMonkey 1.1/2007011111])
# [23:40] * Joins: mw_ (chatzilla@84.41.169.151)
# [23:40] * mw_ is now known as mw
# [23:43] * mw is now known as mw22
# Session Close: Thu Apr 05 00:00:00 2007

The end :)