00:03:39 <hasather> hasather has left #html-wg
00:06:56 <ddailey> ddailey has joined #html-wg
00:09:09 <ddailey> I agree with anne -- http://www.456bereastreet.com/archive/200705/help_keep_accessibility_and_semantics_in_html/#comment57 makes very good sense
00:10:25 <Dashiva> anne = mattur?
00:13:19 <ddailey> Not sure ... at [16:32] in http://krijnhoetmer.nl/irc-logs/html-wg/20070512
00:13:53 <ddailey> I assumed this was anne -- but it may have been someone presuming to speak for anne
00:15:16 <hsivonen> ddailey: anne said he liked the comment
00:15:35 <hsivonen> ddailey: doh. I misread what you sai
00:15:37 <hsivonen> d
00:15:40 <hsivonen> never mind
00:15:53 <ddailey> hsivonen: I liked it too
00:16:43 <othermaciej> I dunno who "mattur" is, but he or she makes a good point
00:19:40 <ddailey> He she or it makes it almost self evident.
00:22:21 <ddailey> Perhaps the other perspective fears that a descriptivist grammar is mutagenic
00:23:08 <Dashiva> Indeed
00:24:22 <ddailey> might there be some way to convince people that the future will not degrade into chaos?
00:25:43 <MikeSmith> othermaciej - /me wishes you had auto-update for Webkit nightlies
00:26:25 <Philip`> http://web.mac.com/reinholdpenner/iWeb/Software/NightShift.html ?
00:26:30 <othermaciej> MikeSmith: NightShift
00:26:36 <othermaciej> I should add a link to webkit.org
00:27:46 <ddailey> for example: showing a migration path that includes ample reassurance that life will still be good after 2010
00:28:33 <ddailey> are nightly builds for webkit equivalent to nightly builds for safari?
00:28:49 <ddailey> or how closely coupled are the two?
00:30:34 <Philip`> ddailey: I think http://webkit.org/blog/101/back-to-basics/ tries to explain that
00:30:55 <ddailey> thanks Philip`
00:30:57 <MikeSmith> othermaciej - just downloaded NightShift ... very cool -- thanks
00:34:23 <ddailey> othermaciej and colleagues may be pleased to know that some "customers" now just assume that Safari / OSX widgets exist everywhere. Reminds me of 1985.
00:36:16 <ddailey> Mac-aware users started assuming a GUI was possible everywhere
00:42:08 <ddailey> they rather succeeded in convincing others that it was worth looking at
01:17:29 <ddailey> ddailey has left #html-wg
01:31:49 <gavin_> gavin_ has joined #html-wg
01:53:24 <MikeSmith> MikeSmith has joined #html-wg
03:39:13 <gavin_> gavin_ has joined #html-wg
04:55:13 <hyatt> hyatt has joined #html-wg
05:46:20 <gavin_> gavin_ has joined #html-wg
06:11:52 <hyatt> hyatt has joined #html-wg
06:25:18 <Zeros> Zeros has joined #html-wg
06:28:43 <dbaron> dbaron has joined #html-wg
06:40:18 <Roger> Roger has joined #html-wg
07:04:41 <Lachy> Lachy has joined #html-wg
07:34:18 <Lachy> Lachy has joined #html-wg
07:53:19 <gavin_> gavin_ has joined #html-wg
08:03:02 <myakura> myakura has joined #html-wg
08:16:10 <myakura> myakura has joined #html-wg
08:40:06 <ROBOd> ROBOd has joined #html-wg
08:48:48 <zcorpan_> zcorpan_ has joined #html-wg
09:07:04 <Shunsuke> Shunsuke has joined #html-wg
09:45:45 <Shunsuke> Shunsuke has joined #html-wg
09:45:49 <hasather> hasather has joined #html-wg
09:58:32 <tH> tH has joined #html-wg
10:00:46 <gavin_> gavin_ has joined #html-wg
10:04:14 <jdandrea> jdandrea has joined #html-wg
10:16:48 <Shunsuke> Shunsuke has joined #html-wg
10:24:57 <Shunsuke> Shunsuke has joined #html-wg
11:01:17 <loic> loic has joined #html-wg
11:14:07 <Shunsuke> Shunsuke has joined #html-wg
12:07:37 <gavin_> gavin_ has joined #html-wg
12:31:08 <ddailey> ddailey has joined #html-wg
12:31:30 <ddailey> ddailey has left #html-wg
13:20:05 <Shunsuke> Shunsuke has joined #html-wg
13:37:18 <dk> dk has joined #html-wg
13:56:42 <gsnedders> gsnedders has joined #html-wg
14:30:32 <Roger> Roger has joined #html-wg
14:32:07 <gavin_> gavin_ has joined #html-wg
14:51:31 <zcorpan_> zcorpan_ has joined #html-wg
15:07:11 <Lachy> Lachy has joined #html-wg
16:35:13 <zcorpan_> zcorpan_ has joined #html-wg
16:39:05 <gavin_> gavin_ has joined #html-wg
17:47:13 <dbaron> dbaron has joined #html-wg
18:11:18 <zcorpan_> zcorpan_ has joined #html-wg
18:14:08 <tH> tH has joined #html-wg
18:26:43 <kingryan> kingryan has joined #html-wg
18:45:53 <sbuluf> sbuluf has joined #html-wg
19:20:11 <hasather> hasather has left #html-wg
19:20:40 <hasather> hasather has joined #html-wg
19:32:31 <dbaron> ok, I'm unsubscribing from www-html
19:32:48 <dbaron> tired of the duplicate messages, and participation by reading occasional messages doesn't seem to be welcome
19:35:12 <anne> FWIW: I agree with you that it would be nice if HTML5 defined all features of HTML in use on the web
19:35:37 <dbaron> in use on the Web is a little strong
19:35:50 <dbaron> that includes a lot of proprietary stuff that is very rarely used
19:37:49 <Lachy> dbaron, what gave you the idea that your input wasn't welcome?  It just seemed like a slight misunderstanding of what was being discussed.
19:38:08 <dbaron> how was I supposed to know that that was being discussed?
19:38:18 <dbaron> It's not mentioned in your message or any of the ones preceding it in the thread
19:38:36 <dbaron> you can't have a 300 person discussion without being clear about what you're saying ,sorry
19:39:32 <Lachy> I just thought it was implied that we were talking about what authors could use
19:40:02 <anne> Hmm, yeah, I guess rarely used stuff should be excluded somehow. Like <t:video>...
19:40:50 <anne> I meant things like <frameset>, <marquee>, <body vlink>, etc.
19:47:16 <othermaciej> othermaciej has joined #html-wg
19:59:39 <tH> tH has joined #html-wg
20:02:17 <zdenko> zdenko has joined #html-wg
20:06:48 <schepers> dbaron, please don't unsubscribe... people like you are crucial to HTML5's success
20:13:29 <anne> www-html isn't
20:14:48 <schepers> oh, right, ok
20:16:34 <tH> tH has joined #html-wg
20:18:28 <hsivonen> oh. there's been a whole thread on www-html since I unsubscribed
20:18:59 <anne> same thing happened when I unsubscribed a month ago :)
20:20:37 <hsivonen> anne: well, I unsubscribed yesterday
20:21:48 <asbjornu> asbjornu has left #html-wg
20:25:24 <zcorpan_> zcorpan_ has joined #html-wg
20:25:26 <gavin_> gavin_ has joined #html-wg
20:45:40 <myakura> myakura has joined #html-wg
21:00:24 <jdandrea_> jdandrea_ has joined #html-wg
21:14:55 <hyatt> hyatt has joined #html-wg
21:16:43 <hyatt> dbaron: you there?
21:19:38 <dbaron> hyatt, yes
21:23:35 <hyatt> dbaron: i sent out some more details
21:23:41 <hyatt> about the idea for this baseline property
21:23:46 <hyatt> i actually don't think it would be inherited.
21:24:00 <hyatt> dbaron: in terms of webkit, we basically have a method on our renderobjects called baselinePosition
21:24:14 <hyatt> for inline flows/blocks it's font.ascent() + leading / 2
21:24:22 <hyatt> for replaced elements it is margin top + height + margin bottom
21:24:30 <hyatt> for inline blocks it is the last line box's baseline etc.
21:24:43 <hyatt> i basically want a CSS property that lets me define that value
21:24:49 <hyatt> instead of it being hardcoded for the various element types
21:25:02 <hyatt> so i don't think the property would need to be inherited
21:25:05 <hyatt> since when set on say a <div>
21:25:18 <hyatt> anyone who needed to vertically align to the baseline would align to that spot
21:25:49 <dbaron> well, that wouldn't address your use case, I don't think, since it wouldn't affect the position of the first line when in the normal flow
21:26:07 <hyatt> it wouldn't?
21:26:19 <hyatt> when set on a block it would establish the baseline's position
21:26:23 <dbaron> Blocks don't normally care about their block baseline
21:26:43 <hyatt> well, it would establish the baseline of the "root line"
21:26:53 <hyatt> e.g., in the sense that :first-line { font-size: 24px }
21:27:01 <dbaron> so why shouldn't it do the same for inline-blocks?
21:27:25 <dbaron> your baselinePosition method seems to mix the baseline as applied to the inside (block) with baseline as applied to the outside (inline-block)
21:27:26 <hyatt> well, inline-blocks have a duality that makes it hard to decide what the property would mean
21:27:41 <hyatt> our baselinePosition method in webkit takes a bool
21:27:42 <hyatt> it's dual
21:27:48 <hyatt> so good point.
21:27:58 <hyatt> an inline-block has two baselinePositions in our code
21:28:00 <hyatt> the outside one and the inside one
21:28:14 <dbaron> one option is to make the property apply only to blocks, and set their baseline-inside
21:28:20 <dbaron> and not be inherited
21:28:23 <hyatt> yeah
21:28:25 <hyatt> that would work
21:28:35 <hyatt> i think having both props is useful
21:28:40 <hyatt> one thing we had to hardcode for example
21:28:44 <hyatt> is the baseline position of checkboxes
21:28:48 <dbaron> this seems the least dangerous in terms of messing up the idea that the model generally tries to lead to things not overlapping
21:28:52 <hyatt> somethign like a checkbox is an "image"
21:29:03 <hyatt> but it needs to establish a baseline other than marginTOp + height + marginbottom
21:29:08 <dbaron> but it would still lead to bad results if a large image or something in a bigger font ended up in the first line
21:29:13 <hyatt> since you'd like to be able to set a baseline at an aesthetically pleasing point 
21:29:30 <hyatt> dbaron: yeah this property is all about pixel level control
21:29:34 <hyatt> which is giving the author rope
21:29:39 <hyatt> potentially to hang themselves 
21:29:56 <hyatt> it may be unsuitable for a standard
21:30:00 <hyatt> i don't feel strongly about it
21:30:10 <hyatt> we can always add in the hack just for the people who need it
21:30:15 <hyatt> but i thought it was worth bringing up
21:30:46 <dbaron> ok; I was scared you were trying to push it in and were already implementing
21:30:52 <hyatt> (this is post-leopard too, so there's not any rush)
21:30:57 <hyatt> nope
21:34:11 <Philip`> Philip` has joined #html-wg
21:41:40 <hyatt> dbaron: i'd point out that line-height is "dangerous" in that it can easily cause lines to overlap
21:46:06 <dbaron> hyatt, though only when less than 1
21:46:16 <hyatt> irght
21:46:45 <dbaron> or less than 'normal', anyway
21:47:47 <hyatt> i wish the css wg wasn't closed
21:47:55 <hyatt> i hate that all these conversations take place on a private list
21:48:01 <hyatt> i should send stuff to www-style instead 
21:49:34 <hyatt> Hixie: ping
21:50:44 <hyatt> Hixie: regarding your comment in http://bugs.webkit.org/show_bug.cgi?id=13696
21:50:57 <hyatt> Hixie: html5 was more restrictive when compared with firefox
21:51:02 <hyatt> Hixie: i went ahead and matched firefox
21:51:07 <hyatt> which reopened in more circumstances
21:55:11 <hyatt> Hixie: i'd be curious to try my test case in WinIE
21:55:29 <hyatt> Hixie: this is not about the set of tags that reopen
21:55:45 <hyatt> Hixie: this is about the set of tags that (when closed) cause those tags to reopen when popping
21:55:57 <hyatt> which should be nearly everything
21:56:11 <hyatt> except for table stuff and selects basically
21:56:24 <hyatt> (and for some odd reason ffx didn't reopen object but did for embed, applet, canvas)
21:56:27 <hyatt> (so i matched ffx)
21:56:37 <hyatt> reopen across </object>
22:07:00 <zcorpan_> http://simon.html5.org/test/html/parsing/residual.html
22:07:21 <zcorpan_> TABLE is red in ie7
22:07:32 <zcorpan_> COL and COLGROUP too
22:07:55 <zcorpan_> after TABLE, everything is green (also things that probably should be black)
22:13:24 <hyatt> wow so winie reopens even more than ffx does
22:14:35 <zcorpan_> at the TABLE, it nests the rest of the document inside that FONT
22:14:52 <hyatt> oh i may have missed a close
22:14:56 <hyatt> or it could have to do with how it recovered
22:15:20 <hyatt> if you see red, it means WinIE reopened
22:15:23 <zcorpan_> TABLE: <font><table><font class="fail"></table>All of this should be green.</font>
22:15:37 <hyatt> oh i should just throw in an extra </font> in those examples
22:15:48 <hyatt> </font></font>
22:15:56 <hyatt> since it will be harmless in the other browsers
22:17:04 <zcorpan_> in opera everything is green after the OBJECT
22:18:44 <hyatt> hey if you cleaned that test up and noted what each browser does that would rule
22:18:58 <hyatt> the test right now basically shows what ffx and safari d
22:18:59 <hyatt> o
22:18:59 <zcorpan_> sure
22:21:33 <zcorpan_> test cleaned up, also uploaded to live dom viewer
22:22:13 <zcorpan_> ok, ie7 again...
22:23:33 <zcorpan_> these are black: APPLET BUTTON MARQUEE. these are red: COL COLGROUP TABLE
22:24:25 <hyatt> fascinating
22:24:40 <hyatt> wow i should add applet button marquee
22:24:44 <hyatt> i should probably just add embed too
22:25:05 <hyatt> i'm scared to reopen col/colgroup/table
22:25:08 <hyatt> even if winie doe
22:30:01 <zcorpan_> zcorpan_ has joined #html-wg
22:31:08 <zcorpan_> ie6 is same as ie7
22:31:15 <zcorpan_> all are green in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070503 Minefield/3.0a5pre
22:32:59 <zcorpan_> opera 9.20 build 8771: these don't include the test text at all: APPLET FIELDSET LEGEND. these are black: BUTTON CANVAS. these are red: OBJECT PARAM 
22:33:20 <gavin_> gavin_ has joined #html-wg
22:41:01 <zcorpan> zcorpan has joined #html-wg
23:20:33 <Philip`> zcorpan: In what way is it lying?
23:20:45 <Philip`> (About non-tree DOM, I guess?)
23:21:15 <zcorpan> Philip`: for the residual style test, it claims that everything is nested inside each FONT as a very deep tree
23:21:48 <Philip`> Ah
23:58:21 <hyatt> hyatt has joined #html-wg