15:44:26 <RRSAgent> RRSAgent has joined #CSS
15:44:26 <RRSAgent> logging to http://www.w3.org/2009/08/05-CSS-irc
15:44:32 <glazou> Zakim, this will be Style
15:44:32 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 16 minutes
15:55:27 <dsinger> dsinger has joined #css
15:56:07 <Zakim> Style_CSS FP()12:00PM has now started
15:56:14 <Zakim> +dsinger_
15:56:33 <dsinger> zakim, dsinger_ is dsinger
15:56:33 <Zakim> +dsinger; got it
15:56:40 <dsinger> zakim, mute me
15:56:40 <Zakim> sorry, dsinger, muting is not permitted when only one person is present
15:56:46 <Zakim> + +1.650.766.aaaa
15:57:00 <dsinger> zakim, mute me
15:57:00 <Zakim> dsinger should now be muted
15:57:37 <dsinger> zakim, who is here?
15:57:37 <Zakim> On the phone I see dsinger (muted), +1.650.766.aaaa
15:57:37 <Zakim> On IRC I see dsinger, RRSAgent, Zakim, glazou, bradk, shepazu, dbaron, MoZ, myakura, annevk, Lachy, jdaggett, plinss, anne, karl, krijnh, plinss_, Bert, Hixie, fantasai, trackbot
15:57:42 <Zakim> -dsinger
15:58:09 <Zakim> +dsinger
15:58:18 <dsinger> zakim, mute me
15:58:18 <Zakim> dsinger should now be muted
15:58:32 <Zakim> +plinss
15:58:36 <oyvinds> oyvinds has joined #css
15:58:56 <Zakim> +Daniel_Glazman
15:59:44 <glazou> Zakim, aaaa is Bradkemper
15:59:44 <Zakim> +Bradkemper; got it
16:00:06 <bradk> thanx
16:00:13 <glazou> Zakim, aaaa is bradk 
16:00:15 <Zakim> sorry, glazou, I do not recognize a party named 'aaaa'
16:00:19 <glazou> sigh
16:00:32 <dbaron> Zakim, Bradkemper is bradk
16:00:32 <Zakim> +bradk; got it
16:00:38 <glazou> thx dbaron 
16:01:48 <dbaron> yes
16:02:10 <dbaron> the only sip client that works for me tends to only work once per time it's started
16:02:24 <Zakim> +Bert
16:02:56 <dbaron> and if you try to make a call before it's fully initialized (which takes more than a minute), you have to start all over
16:02:59 <Zakim> +[Microsoft]
16:03:15 <Zakim> +??P10
16:03:45 <sgalineau> sgalineau has joined #css
16:04:36 <hyatt> hyatt has joined #css
16:05:01 <fantasai> ScribeNick: fantasai
16:05:04 <sgalineau> Zakim, [Microsoft] has alexmog, arronei, sylvaing
16:05:04 <Zakim> +alexmog, arronei, sylvaing; got it
16:05:13 <Zakim> +[Mozilla]
16:05:38 <Zakim> +hyatt
16:05:47 <dbaron> Zakim, [Mozilla] has dbaron
16:05:47 <Zakim> +dbaron; got it
16:07:51 <Zakim> -plinss
16:08:02 <glazou> http://wiki.csswg.org/spec/css2.1#issue-120
16:08:27 <Zakim> +plinss
16:09:18 <dbaron> this is issue 8 in the email
16:10:36 <fantasai> fantasai: I'm not suggesting we solve the issue on the call, but that we decide how to approach it
16:11:04 <ChrisL> ChrisL has joined #css
16:11:29 <fantasai> fantasai: whether we want to audit the entire spec to make sure the explicit lists are everywhere they need to be and in sync
16:11:53 <fantasai> fantasai: or whether we want to remove explicit lists and define special display types in terms of blocks
16:12:16 <Zakim> +ChrisL
16:12:16 <fantasai> Bert: I think it's easier to have explicit lists, make sure we think about where the exceptions are
16:12:35 <fantasai> Daniel: I think it's easier to have just a sentence saying table-captions are like blocks, much fewer edits
16:12:45 <fantasai> dbaron: Need to be careful, it's like a block inside but not outside
16:13:06 <ChrisL> rrsagent, here
16:13:06 <RRSAgent> See http://www.w3.org/2009/08/05-CSS-irc#T16-13-06
16:13:15 <fantasai> fantasai: There are many places in the spec that mention blocks in passing, we can't have explicit lists everywhere
16:13:27 <ChrisL> rrsagent, make logs public
16:13:34 <dbaron> I think we should leave it to the editor to propose an appropriate fix.
16:13:38 <fantasai> fantasai: Maybe at the top of the section, "blocks in these cases means ..."
16:14:07 <alexmog> alexmog has joined #css
16:14:42 <glazou> that's not personel, that's a decision
16:14:44 <fantasai> dbaron and Bert discuss lineboxes and baselines
16:14:57 <fantasai> RESOLVED: Invite Tab Atkins as Invited Expert
16:15:01 <glazou> thx
16:16:26 <fantasai> fantasai: It's not as simple as a sentence fix here. Basically we need to audit the spec, because we have a lot of this kind of problem
16:16:49 <fantasai> fantasai: Question here is which approach should the person auditing the spec
16:16:54 <fantasai> take
16:16:54 <dsinger> as long as it is, in fact, true everywhere...
16:17:11 <glazou> dbaron, I hear nothing special here
16:18:20 <fantasai> ChrisL asks what the proposals are
16:18:40 <fantasai> fantasai: First is to audit the spec and make sure there explicit lists whereever we talk about blocks, and make sure those lists are in sync
16:19:17 <hyatt> same. up to the editor imo.
16:19:32 <fantasai> fantasai: Second is to audit the spec to just talk about blocks, and then in the definition for table-caption etc. define those to behave exactly like blocks except ... and list the exceptions
16:19:49 <dbaron> "letting the editor decide" == doesn't need to make the decision while we wait
16:20:21 <fantasai> Several in favor of second option, Bert in favor of first (?), dbaron and hyatt want editor to decide
16:21:50 <fantasai> dbaron: I think the solution here is to reword the sentence to define a block's baseline
16:22:20 <fantasai> dbaron: So maybe Bert's suggestion to rename to line box's baseline is good
16:22:30 <fantasai> ACTION: Bert and fantasai solve this issue
16:22:30 <trackbot> Created ACTION-171 - And fantasai solve this issue [on Bert Bos - due 2009-08-12].
16:22:30 <dbaron> (rename and make it a definition)
16:22:31 <glazou> http://wiki.csswg.org/spec/css2.1#issue-129
16:24:27 <fantasai> dbaron explains the issue
16:24:42 <dsinger> dsinger has joined #css
16:24:59 <Zakim> +[Apple]
16:25:09 <Zakim> -dsinger
16:25:13 <fantasai> The way url() is defined in the tokenizer, if something starts to match url() but doesn't end
16:25:15 <dsinger> zakim, [apple] has dsinger
16:25:15 <Zakim> +dsinger; got it
16:25:30 <fantasai> then the tokenizer has to go back and retokenize as something else
16:25:36 <fantasai> which is not what anyone does
16:25:49 <fantasai> dbaron: And we have prose that contradicts this, at least for the URL case
16:26:01 <dbaron> I think
16:26:19 <fantasai> Bert doesn't want to change the grammar
16:26:27 <fantasai> Others don't want to change implementations
16:27:00 <fantasai> dbaron: What the spec says is that given
16:27:02 <fantasai> <style>
16:27:07 <fantasai> p { color: red; }
16:27:11 <fantasai> h1 { color: red; }
16:27:14 <fantasai> </style>
16:27:21 <fantasai> (insert /* after <style>)
16:27:23 <Bert> Currently, "/*" is two DELIMs, we can still use it for something. After Zack's change, "/*" becomes reserved.
16:27:30 <glazou> fantasai: with a comment start before 1st rule
16:27:31 <fantasai> implementations should treat /* as an invalid selector
16:27:37 <dbaron> Bert, we can't use it for something, since it starts a comment
16:27:43 <fantasai> glazou, yes, it got eaten by my IRC client :)
16:27:47 <glazou> oh ok :)
16:27:51 <dbaron> Bert, if we used it, we wouldn't be able to have comments anywhere later in the style sheet
16:28:59 <fantasai> Peter: I think it's extremely dangerous to use /* as a delimiter for anything other than comments
16:29:22 <fantasai> Bert: The grammar is the most stable part of the spec, we should not touch that
16:29:57 <dbaron> "User agents must close all open constructs (for example: blocks, parentheses, brackets, rules, strings, and comments) at the end of the style sheet. For example: "
16:30:03 <fantasai> ChrisL: If the grammar is stable, but a portion of it has not been implemented and nobody wants to implement it, then it may be stable but it's wrong
16:30:08 <glazou> Zakim, who is noisy?
16:30:19 <Zakim> glazou, listening for 10 seconds I could not identify any sounds
16:30:21 <fantasai> dbaron: We also have prose that contradicts the grammar very clearly
16:31:07 <fantasai> fantasai: Prose trumps grammar. I think we should fix the grammar.
16:31:16 <plinss> http://lists.w3.org/Archives/Public/www-style/2009Jun/att-0164/unterm-css.html
16:32:58 <dbaron> I think we've already fixed Firefox on the trunk
16:33:19 <fantasai> Sylvain: We backtrack the first and last, but not the middle two
16:33:24 <hyatt> lol
16:33:35 <fantasai> Firefox backtracks the middle two, but not the first and the last
16:33:50 <fantasai> Glazou: We should fix this
16:34:17 <plinss> Safari does not backtrack for any
16:34:20 <sgalineau> IE7 did not backtrack anywhere
16:34:32 <fantasai> Opera?
16:35:02 <oyvinds> 9.64 backtracks the last three, but my internal build none
16:35:17 <dbaron> I guess I have a fix to fix the backtracking in my own tree that's not checked in yet.
16:35:33 <dbaron> I'll have to figure out which patch that is. :-)
16:35:39 <fantasai> Brad: No sense in keeping it inconsistent among UAs
16:35:49 <sgalineau> Opera 10 Beta is same as 9.64
16:35:51 <glazou> Zakim, who is on the call?
16:35:51 <Zakim> On the phone I see bradk, Daniel_Glazman, Bert, [Microsoft], ??P10, [Mozilla], hyatt, plinss, ChrisL, [Apple]
16:35:53 <Zakim> [Apple] has dsinger
16:35:53 <Zakim> [Mozilla] has dbaron
16:35:53 <fantasai> Daniel: I'm happy with the proposal
16:35:54 <Zakim> [Microsoft] has alexmog, arronei, sylvaing
16:36:09 <fantasai> Bert doesn't have a problem with the proposal itself, just doesn't want to change the grammar
16:36:27 <fantasai> Daniel: yes
16:36:30 <fantasai> Bert: No, but won't block
16:36:35 <fantasai> Brad: fix it, dont' care how
16:36:38 <fantasai> Sylvain: change it
16:36:39 <hyatt> yup
16:36:43 <fantasai> Alex, Arron: change
16:36:48 <fantasai> fantasai: in favor
16:36:51 <hyatt> in favor yes
16:36:53 <fantasai> dbaron: in favor
16:37:03 <fantasai> Peter: yes
16:37:04 <ChrisL> fix as proposed
16:37:08 <dbaron> Ah, yes, I've had this patch to rewrite url() parsing in my tree for ages that I should really do something about...
16:37:14 <fantasai> dsinger: whatever hyatt says :)
16:37:27 <fantasai> Daniel: Vast majority for yes.
16:37:48 <fantasai> RESOLVED: Proposal accepted for CSS 2.1 issue 129
16:37:59 <glazou> http://wiki.csswg.org/spec/css2.1#issue-130
16:38:57 <fantasai> dbaron: I think this is as intended
16:39:15 <fantasai> fantasai: No, it's a problem. The example lists keywords that don't exist. So the example is inconsistent with the normative prose
16:39:54 <fantasai> Sylvain: We're just reserving them for future use
16:40:05 <fantasai> fantasai: But if we want to do that, we have to do it normatively, not in an example
16:41:32 <fantasai> Bert: We edited the spec to include those keywords because we noticed they're defined in later specs, but not listed
16:42:09 <fantasai> dbaron: I don't think it should be an example, it should just be that list
16:42:18 <fantasai> (because for font-family, it's exhaustive)
16:43:24 <dbaron> font shorthand requires size and family, and only lh and family after size, because the syntax for family is so broad
16:43:49 <fantasai> ChrisL: Making the list normative is good, but should probably also call those keywords out explicitly
16:44:42 <fantasai> I suggest removing those keywords from the example list, removing 'e.g.', and adding a sentence that says "'initial' and 'default' are reserved as keywords for future use and must also be quoted"
16:45:26 <dsinger> and if a font with that name is desired, they must be quoted. yes.
16:45:58 <fantasai> RESOLVED: Proposal accepted with "when used as font names" appended
16:46:14 <glazou> http://wiki.csswg.org/spec/css2.1#issue-133
16:47:54 <glazou> dbaron: lol
16:48:12 <fantasai> dbaron: this is only one out of many issues for table heights/widths and we wanted to postpone them
16:50:31 <dsinger_> dsinger_ has joined #css
16:50:40 <fantasai> fantasai: If it's not defined, we should say it's not defined
16:51:08 <fantasai> fantasai: we don't say that row-group heights are undefined, just tables and rows
16:52:18 <fantasai> Bert: Add a sentence in 17.5.3 saying that height is undefined for row groups
16:52:28 <fantasai> RESOLVED: Accepted, Bert to word and edit
16:52:42 <glazou> http://wiki.csswg.org/spec/css2.1#issue-134
16:53:29 <dbaron> the first issue 134! :-)
16:56:42 <fantasai> Brad: Is there any reason why we can't use percentage offsets on relpos children of an auto-height block?
16:57:24 <fantasai> dbaron: It's probably ok, though I'm a little concerned if there's overflow set... though I guess it's not a problem even then, just weird behavior
16:57:38 <fantasai> Brad: Is it going to break anything if people implement it this way?
16:57:58 <fantasai> fantasai: Apparently IE6 did it, so probably not
16:58:19 <fantasai> Brad: unless they're doing two things and assuming IE does it but others dont'
16:58:54 <fantasai> Bert: I don't see why it can't work
16:59:14 <hyatt> seems fine
16:59:32 <fantasai> RESOLVED: Close no change
16:59:47 <glazou> http://lists.w3.org/Archives/Public/www-style/2009Jul/0025.html
17:00:39 <Zakim> -hyatt
17:00:40 <Zakim> -ChrisL
17:00:42 <Zakim> -[Apple]
17:00:44 <Zakim> -[Microsoft]
17:00:46 <Zakim> -Daniel_Glazman
17:00:48 <Zakim> -[Mozilla]
17:00:52 <Zakim> -bradk
17:00:54 <Zakim> -plinss
17:00:56 <Zakim> -??P10
17:00:58 <Zakim> -Bert
17:01:00 <Zakim> Style_CSS FP()12:00PM has ended
17:01:03 <Zakim> Attendees were dsinger, +1.650.766.aaaa, plinss, Daniel_Glazman, bradk, Bert, alexmog, arronei, sylvaing, hyatt, dbaron, ChrisL
17:35:45 <sgalineau> sgalineau has joined #css
17:47:24 <dsinger> dsinger has joined #css
17:49:37 <dsinger> dsinger has joined #css
18:03:55 <fantasai> RRSAgent: make logs public
18:17:26 <dbaron> dbaron has joined #css
18:41:23 <sgalineau> sgalineau has joined #css
18:54:26 <Zakim> Zakim has left #CSS
19:43:49 <dbaron> anne, annevk,  I have references for the css3-namespace test suite, if you're interested... I could easily check them (and the reftest.list) into CVS.
19:49:11 <fantasai> dbaron: sure, go ahead
20:36:11 <dbaron> annevk, reftest references :-)
20:39:36 <dbaron> hmm, if I dump them in the same directory, will it mess up the script that generates the index?
20:39:58 <annevk> fantasai might know; I haven't done anything with that
20:40:17 <fantasai> dbaron, yes
20:40:28 <fantasai> dbaron, but the script that generates the index needs help currently anyway
20:40:52 <fantasai> dbaron, if the references can handle a separate directory, that might make it easier
20:41:01 <dbaron> they can
20:41:27 <fantasai> dbaron, but the scripts need to be updated for a lot of things and namespaces currently needs hand-tweaking anyway
20:41:32 <dbaron> I could do a reftest/ subdirectory or a references/ subdirectory.
20:41:43 <dbaron> and it could be a subdirectory of src/ or next to src/
20:41:47 <dbaron> any preference?
20:41:52 <fantasai> how about a reftest/ subdirectory of the src directory
20:41:55 <fantasai> and put the manifest in there?
20:41:58 <dbaron> ok
20:42:01 <fantasai> Then we can add an explanation, too
20:42:06 <dbaron> was planning to put the manifest there too
20:44:54 <dbaron> ok, done
20:45:03 <fantasai> cool
20:47:06 <annevk> btw, some guys at Opera would really like some guidance on how the vertical text overflow ellipsis needs to be done instead
20:47:50 <annevk> also, I don't think I ever got a reply to http://lists.w3.org/Archives/Public/www-style/2009Jun/0112.html
20:50:17 <fantasai> annevk: make a pseudo-element, that should handle all use cases
20:51:35 <fantasai> anne: You mean that if I scroll, the content is still cut off and I just get blank space?
20:51:38 <fantasai> that doesn't eem right
21:02:47 <annevk> a pseudo-element?!
21:03:20 <annevk> well "right" depends on the definition I suppose
21:03:34 <annevk> I assume that what we have is more trivial than what you seem to want
21:03:51 <fantasai> the main use case is for text input fields, right?
21:03:58 <fantasai> that was the original one anyway
21:04:12 <annevk> was that why IE added it?
21:04:17 <annevk> i somehow doubt it
21:04:23 <fantasai> if they're scrollable, I don't want to see an ellipsis as I scroll through
21:04:28 <fantasai> I want to see the actual content
21:06:37 <annevk> the typical case is for overflow:hidden afaict
21:06:46 <annevk> we haven't heard any authors complain about our impl anyway
21:06:56 <annevk> apart from not having it applied vertically
21:08:03 <fantasai> do Safari and IE apply it vertically?
21:08:56 <fantasai> both is also weird
21:12:30 <fantasai> *sigh*
21:12:40 <fantasai> What do you want it to do for "vertically", anne?
21:13:27 <fantasai> it has to be a separate syntax, but we could use the same property if it's close enough
21:14:18 <fantasai> Send a proposal to www-style for the behavior, catalog what you want to happen for various values of overflow and what happens when they trigger
21:14:25 <fantasai> we'll discuss the syntax based on that
21:15:16 <fantasai> also, what happens when the overflow is not text
21:15:17 <fantasai> etc
21:23:19 <annevk> well, with vertically I mean that if you have three lines and room for two you show an ellipsis at the end of the second line
21:23:42 <annevk> I already made a proposal once and it was rejected
21:24:03 <annevk> so I guess now I'm asking for answers to my questions to figure out what a good alternative would be
21:31:30 <fantasai> your proposal was to make the same syntax affect "vertical overflow"
21:31:56 <fantasai> in cases where there's vertical overflow instead of horizontal overflow
21:31:58 <fantasai> that was rejected
21:32:13 <fantasai> The concept of having a control for ellipsis on vertical overflow was not rejected
21:32:23 <fantasai> But the whole thing is very vaguely defined
21:32:34 <fantasai> and I don't really understand what behavior you want anyway
21:43:55 <hyatt> we've had to invent so much ellipsis crap
21:44:02 <hyatt> you know what people really want
21:44:07 <hyatt> is to define how overflow looks on the last line onlyl
21:44:08 <fantasai> no, what
21:44:10 <hyatt> and have a pseudo element
21:44:13 <hyatt> for control of what to do
21:44:25 <hyatt> safari rss we had to do something like that
21:44:32 <hyatt> we have ellipses on the last line of an article
21:44:36 <hyatt> and we have a Read More link
21:44:44 <hyatt> and that has to just appear at the end of the line
21:44:59 <hyatt> we had ot just make up custom garbage to do it :)
21:45:02 <fantasai> you want display: run-out for that kind of stuff :)
21:45:44 <fantasai> but, yeah, I agree we need a pseudo-element for vertical overflow
21:45:47 <hyatt> it's probably too specializd
21:45:53 <hyatt> the safari rss stuff
21:45:56 <fantasai> people want to put different kinds of text, styling, icons, whatever
21:45:57 <hyatt> to ever be specified
21:46:00 <fantasai> yeah
21:46:10 <fantasai> but display: run-out would be useful for other things too
21:46:25 <fantasai> I've seen it used to give the author of an article
21:46:38 <hyatt> this article annoys me
21:46:39 <hyatt> https://developer.mozilla.org/web-tech/2009/08/04/background-images-no-longer-restricted-to-original-size-explore-the-space-with-background-size/
21:46:53 <hyatt> "A note to would-be early adopters: this is one reason why Mozilla sometimes holds off on implementing features that are part of a working draft; implement it when it’s too new and you’ll find the carpet pulled out from underneath you"
21:46:59 <hyatt> eh
21:47:40 <hyatt> it was hardly "too new" when webkit implemented it
21:47:53 <hyatt> </rant>
21:48:14 <fantasai> heh
21:48:17 <hyatt> we'll just stop implementing stuff and let mozilla tell us when we should.
21:48:38 <hyatt> </okreallyendrant>
21:48:44 <fantasai> lol
21:48:57 <fantasai> roc's got a good point about text-overflow, though
21:49:05 <fantasai> it is /so/ poorly defined
21:49:07 <hyatt> i hate it
21:49:13 <hyatt> it's so weird
21:49:28 <hyatt> having to specify overflow:hidden (and usually white-space:nowrap)
21:49:35 <hyatt> just to get text to truncate
21:49:44 <fantasai> yeah, I thought we were going to get rid of that requirement
21:49:54 <fantasai> you suggested it a long time ago, and I was going to put it in the spec
21:50:00 <hyatt> and the fact that it can apply to lines in the middle of your block
21:50:02 <hyatt> i don't really get
21:50:24 <fantasai> I would be happy with a definition that only applies to the last line
21:50:34 <hyatt> the way people seem to always use this stuff is for single lines of text
21:50:36 <fantasai> but not with one that applies to lines in the middle of the block sometimes
21:50:40 <fantasai> and only the last line other times
21:50:40 <hyatt> it's mostly for controls and things
21:50:43 <hyatt> or lines in a tree/table
21:50:44 <hyatt> etc
21:51:02 <hyatt> and people want middle and left truncation too obviously
21:51:12 <fantasai> ?
21:51:18 <hyatt> which may be there
21:51:22 <hyatt> i haven't read the definition lately
21:51:31 <hyatt> middle truncation is common for URLs
21:51:35 <fantasai> ah
21:51:43 <hyatt> where you wan t to be able to see the host name and the page you're on
21:51:49 <hyatt> and the middle stuff tends to be less relevant
21:51:55 <fantasai> that's gotta be customized
21:51:55 <hyatt> you see that in tree controls of bookmarks etc.
21:52:05 <fantasai> because for URLs you want some intelligent matching
21:52:07 <hyatt> well XUL just does its own truncation stuff in mozilla
21:52:13 <hyatt> outside of CSS
21:52:14 <fantasai> to keep the relevant stuff, and not clip out e.g. half the hostname
21:53:26 <fantasai> hyatt, if you think we can revamp the definition for text-overflow without breaking things significantly, I'm happy to help spec it out.
21:53:41 <hyatt> mostly we'd need to look at IE
21:53:48 <fantasai> but I don't want to sit here trying to reverse-engineer all the junk
21:53:51 <hyatt> sounds like roc has done more testing than i have
21:54:00 <hyatt> so maybe he could help explain what he noticed
21:54:02 <fantasai> yeah, we have a bug open on it and someone ran a lot of tests
21:54:13 <fantasai> the results were posted to www-style
21:54:16 <fantasai> and they were still incomplete
21:56:06 <fantasai> if we can get a solid definition for text-overflow, we can pull that and overflow-x/overflow-y and the ink overflow thing into a small spec
21:56:40 <fantasai> but man, I do not want to write the test suite for that :)
21:57:41 <sgalineau> sgalineau has joined #css
21:58:16 <fantasai> sgalineau: hyatt and I were just discussing text-overflow
21:58:45 <hyatt> i was waiting for someone to noticet hat outline actually behaved like ink overflow in webkit and ask why it was so hard to do rofl
21:58:49 <hyatt> if only they knew how i did outline...
21:58:51 <hyatt> and how horrible it is
21:58:52 <hyatt> lol
21:59:17 <hyatt> the ink overflow thing is a pain
21:59:26 <hyatt> if i back up i realize it's the right thing to do
21:59:31 <fantasai> :)
21:59:33 <hyatt> and that mostly it's me being grumpy as an implementer
21:59:35 <hyatt> about doing it
21:59:44 <fantasai> lol
21:59:56 <hyatt> i even have found some bugs in webkit
22:00:00 <hyatt> as i split the two overflow concepts
22:00:13 <hyatt> where using ink overflow was clearly a bug
22:00:31 <fantasai> you mean layout overflow?
22:00:38 <fantasai> 'cuz you didn't have ink overflow before
22:00:44 <hyatt> no places where ink overflow needed to be ignored
22:00:46 <hyatt> and wasn't
22:01:04 <hyatt> jumping to a link for example
22:01:09 <hyatt> you want to jump to the upper left hand corner
22:01:13 <hyatt> we were including the shadows in that
22:01:18 <hyatt> when i don't think you want to :)
22:01:20 <fantasai> :)
22:03:58 <fantasai> sgalineau: http://krijnhoetmer.nl/irc-logs/css/20090805#l-370
22:04:25 <fantasai> sgalineau: would you guys be interested in working with me and hyatt in revamping text-overflow?
22:35:05 <fantasai> hyatt: I merged background-break and border-break into box-break, btw.
22:35:18 <fantasai> hyatt: I also drafted some text for the border-image drop-shadow
22:35:31 <fantasai> hyatt: What do you think of handling spread as described here? http://dev.w3.org/csswg/css3-background/#the-box-shadow 
23:34:35 <Lachy> Lachy has joined #css