IRC log of CSS on 2009-08-05

Timestamps are in UTC.

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