IRC log of css on 2008-10-19
Timestamps are in UTC.
- 07:16:06 [RRSAgent]
- RRSAgent has joined #css
- 07:16:06 [RRSAgent]
- logging to http://www.w3.org/2008/10/19-css-irc
- 07:22:36 [anne]
- anne has joined #css
- 07:31:15 [sylvaing]
- sylvaing has joined #css
- 07:34:57 [jdaggett]
- jdaggett has joined #css
- 07:35:57 [dbaron]
- ScribeNick: dbaron
- 07:36:00 [dbaron]
- Scribe: David Baron
- 07:36:03 [glazou]
- http://wiki.csswg.org/planning/mandelieu-2008
- 07:36:06 [dbaron]
- Meeting: CSS Working Group Face-to-Face meeting
- 07:36:17 [dbaron]
- Topic: Agenda
- 07:36:39 [dbaron]
- Daniel: I just posted wiki URL. Request to discuss CSS2 system colors with another WG, probably tomorrow morning.
- 07:36:58 [dbaron]
- Daniel: Who is attending conflicting meetings?
- 07:37:04 [dbaron]
- Steve: I'm chairing another meeting on Tuesday.
- 07:37:16 [dbaron]
- Anne: I have Web Apps Monday and Tuesday; I'll try to alternate, but both don't have an agenda yet.
- 07:37:41 [dbaron]
- Daniel: To those who won't be here Monday/Tuesday, anything you want discussed today?
- 07:38:10 [dbaron]
- Anne: I want to attend the cross-WG one listed at the bottom of the page ("User control over UI").
- 07:38:30 [dbaron]
- Anne: "Special behavior of BODY" we could do, but it should be trivial.
- 07:39:10 [dbaron]
- Steve: My preference is that things like syntax and selectors occur on Tuesday.
- 07:39:13 [dbaron]
- Elika: Melinda wants paged media on Tuesday.
- 07:39:40 [dbaron]
- Steve: Although I'd prefer paged media not on Tuesday.
- 07:40:53 [dbaron]
- Anne: Dean Jackson wanted to discuss Apple proposals... he's not here now.
- 07:40:57 [dbaron]
- Daniel: maybe Monday
- 07:41:52 [dbaron]
- Anne: We'd like it as well, and Mozilla has implemented parts of it.
- 07:42:50 [dbaron]
- Daniel: <goes rapidly over list of topics>
- 07:43:24 [dbaron]
- Daniel: While everybody is here, we should probably discuss 2 things: (1) next f2f meetings
- 07:43:26 [fantasai]
- Topic: F2Fs next year
- 07:44:06 [dbaron]
- Peter: I'd like 4 2-day meetings.
- 07:44:15 [dbaron]
- Elika: ...
- 07:44:27 [dbaron]
- Steve: I think 3 3-day is more practical... especially given travel budgets.
- 07:44:30 [fantasai]
- Elika: That's tough for people travelling from far away
- 07:44:32 [dbaron]
- Daniel: What time of year?
- 07:44:35 [alexmog]
- alexmog has joined #css
- 07:44:38 [fantasai]
- Elika: It takes a couple days just to adjust to the new time zone
- 07:45:02 [fantasai]
- David: One issue we've had the past few years is that we've put the summer meeting late in the summer and thus very close to the fall meeting
- 07:45:20 [dbaron]
- Daniel: We could do February, June, November...
- 07:46:36 [dbaron]
- John: Can't confirm for sure, but could do one in Tokyo.
- 07:48:59 [dbaron]
- (February)
- 07:49:04 [dbaron]
- ?: Sophia-Antipolis in June?
- 07:49:11 [dbaron]
- Bert: My holidays are first half of June.
- 07:50:09 [dbaron]
- RRSAgent, make logs public
- 07:50:23 [dbaron]
- Daniel: And TPAC in October/November.
- 07:50:54 [sylvaing]
- sylvaing has joined #css
- 07:51:06 [dbaron]
- Daniel: Either Boston or Santa Clara.
- 07:51:53 [dbaron]
- Daniel: Let us know about days that are bad in Feb/Mar and late June.
- 07:52:00 [dbaron]
- Elika: I can't do second half of March.
- 07:52:45 [dbaron]
- Steve: Week of President's Day (US) can be a good week.
- 07:54:04 [dbaron]
- Daniel: I think Haakon may have offered to host in Oslo...
- 07:54:50 [dbaron]
- Daniel: Tentative plan is Tokyo in Feb/Mar, Sophia-Antipolis in June, TPAC in US in Oct/Nov.
- 07:55:18 [sylvaing]
- sylvaing has joined #css
- 07:55:41 [fantasai]
- Daniel needs to check school vacation calendar, prefers to be home 25th of Feb
- 07:55:44 [dbaron]
- Daniel: I'd like to be home 25 Feb.
- 07:56:03 [fantasai]
- Anne: No constraints
- 07:56:27 [fantasai]
- Bert: First 2 weeks of June
- 07:56:31 [fantasai]
- Bert: can't do
- 07:56:52 [fantasai]
- Steve: June is difficult, but I can probably work around it
- 07:57:22 [fantasai]
- Daniel: I prefer after March 2nd
- 07:57:38 [fantasai]
- Alex: MSFT March 18-20 not a good time
- 07:57:54 [fantasai]
- David: I have a weak preference for avoiding US Government holidays
- 07:58:44 [fantasai]
- Peter: no constraints
- 07:58:48 [fantasai]
- John: no constraints
- 07:58:53 [fantasai]
- Elika: Not second half of March
- 07:59:33 [fantasai]
- Alex: Also SxSW is March 13-22
- 08:01:32 [fantasai]
- Discussing dates in June
- 08:01:43 [fantasai]
- Steve prefers week of 22n-26
- 08:02:54 [fantasai]
- Bert is returning on the 23rd
- 08:04:37 [fantasai]
- Elika: I can't do May 29-June1
- 08:06:18 [fantasai]
- Daniel: So, target 24-25-26 June 2009
- 08:06:44 [fantasai]
- Daniel: Target for 1st meeting, 2 first weeks of March
- 08:07:13 [fantasai]
- ACTION: glazou email w3c-css-wg with proposed dates and ask for comments/constraints
- 08:07:13 [trackbot]
- Created ACTION-113 - Email w3c-css-wg with proposed dates and ask for comments/constraints [on Daniel Glazman - due 2008-10-26].
- 08:07:37 [dbaron]
- Topic: Keeping web designers involved as invited experts
- 08:07:38 [fantasai]
- Topic: Web Designers as Invited Experts
- 08:07:50 [fantasai]
- Daniel: Jason Cranford Teague has left the WG
- 08:08:16 [fantasai]
- Daniel: Since his perpsective is exteremely valuable, we wanted to propose to keep him as an Invited Expert to the WG
- 08:08:41 [fantasai]
- Daniel: This raises an issue because AOL is the kind of company that could join the WG, but they are leaving the WG
- 08:08:59 [fantasai]
- Daniel: Jason was never really representing AOL as much as himself and the web designers, so I think it makes sense
- 08:09:20 [fantasai]
- Daniel: I understand from a W3C Process point of view it's difficult, but we really need web designers
- 08:09:52 [fantasai]
- Steve: I would support that. I agree that Jason's contributions are from the perspective of a designer, but I think the precedent it establishes in W3C is potentially dangerous
- 08:10:14 [fantasai]
- John: People who are very hard are people who are technically oriented, but ...
- 08:10:46 [fantasai]
- John: A lot of issues break down to implementation issues, there has to be a balance between making an implementation consistent etc. and what will make it useful and easy for designers
- 08:11:19 [fantasai]
- Daniel: That's a difficulty in this WG. A trivial proposal, a one-liner, can be extremely difficult to implement and most web designers don't understand that
- 08:11:32 [fantasai]
- Daniel: Jason says he has time
- 08:12:11 [fantasai]
- Bert: Has to pass Morrow and W3CM. He's clearly an AOL employee
- 08:12:21 [fantasai]
- Bert and Steve want him here, but are concerned about process stuff
- 08:12:22 [glazou]
- Mauro
- 08:12:29 [dbaron]
- s/Morrow/Mauro/
- 08:12:46 [dbaron]
- Elika: Other people?
- 08:13:25 [dbaron]
- Daniel: We already had this discussion... remember failure of CSS 11?
- 08:14:09 [MoZ]
- MoZ has joined #css
- 08:16:05 [fantasai]
- Daniel: ... strictly speaking, it is difficult to make Jason an official Invited Expert
- 08:16:20 [fantasai]
- Daniel: but almost everything we do here is public, so he can still contribute
- 08:16:35 [fantasai]
- Steve: We have to be careful about IPR
- 08:19:29 [dbaron]
- (various discussion)
- 08:20:56 [fantasai]
- Topic: Margin Collapsing
- 08:21:03 [fantasai]
- Bert: Was wondering about margin collapsing in vertical
- 08:21:30 [fantasai]
- Bert: If you have a vertical block inside a horizontal one
- 08:21:39 [fantasai]
- Alex: That's a yes-or-no question. In our implementation they do collapse
- 08:22:16 [fantasai]
- David: You'd be making a new block formatting context
- 08:22:24 [dbaron]
- (break)
- 08:23:49 [fantasai]
- RESOLVED: make a new block formatting context when block direction switches, margins outside the bfc do collapse
- 08:37:53 [MoZ]
- MoZ has joined #css
- 08:58:19 [dbaron]
- Topic: Special behavior of BODY
- 08:59:25 [dbaron]
- Daniel: Proposal by Simon Pieters is to make the body element in XHTML magic just like in HTML.
- 09:01:04 [mib_apftg8]
- mib_apftg8 has joined #css
- 09:01:43 [dbaron]
- Anne: Was partly implemented per spec, marked at risk, implementations shifted back.
- 09:01:57 [fantasai]
- David: Originally everyone did what simon is proposing
- 09:02:07 [fantasai]
- David: Then the XHTML WG asked us to make this change, and some browsers followed
- 09:02:18 [fantasai]
- David: There are two different quirks. One for background, one for overflow
- 09:02:24 [fantasai]
- David: I think Mozilla followed both briefly
- 09:02:30 [fantasai]
- David: Webkit followed one but not the other
- 09:02:35 [sylvaing]
- sylvaing has joined #css
- 09:02:46 [fantasai]
- David: So we didn't have two implementations of both
- 09:02:51 [SteveZ]
- SteveZ has joined #css
- 09:02:52 [fantasai]
- David: so we marked it at risk
- 09:03:08 [fantasai]
- David: Mozilla, Opera, and Webkit currently treat HTML body and XHTML body the same way
- 09:03:16 [fantasai]
- David: And simon has a test suite for this quirk stuff
- 09:04:10 [dbaron]
- Elika: Can we get these tests in the 2.1 test suite?
- 09:04:28 [fantasai]
- Elika: Anne, make sure they're in the right format and check them into svn?
- 09:04:52 [dbaron]
- David: HTML5 spec wants HTML and XHTML to be treated the same; don't know that it's been discussed in WG.
- 09:05:37 [dbaron]
- Alex: We don't do XHTML yet; would be easiest to not do anything special for XHTML.
- 09:05:53 [dbaron]
- Daniel: That sounds like a consensus?
- 09:06:07 [dbaron]
- Bert: I'd rather do the other way around, but...
- 09:06:20 [dbaron]
- Bert: I think it's ugly but it doesn't break anything.
- 09:06:31 [dbaron]
- Daniel: And it helps people who want to convert a Web page from HTML4 to XHTML.
- 09:06:42 [dbaron]
- Bert: But harder to convert to Docbook or other things.
- 09:06:51 [dbaron]
- Bert: I don't like it, but I don't think it's dangerous, just ugly.
- 09:07:15 [dbaron]
- Peter: I'd almost like to see a way of declaring in CSS that element N should have this behavior.
- 09:07:34 [dbaron]
- Anne: Seems too obscure to complicate the language.
- 09:07:46 [dbaron]
- Elika: Seems like a quirk that we just have to deal with for HTML.
- 09:07:59 [dbaron]
- Elika: It's there because of backwards-compatibility, not because it's useful.
- 09:08:37 [dbaron]
- Bert: But what happens if people create new formats that reuse parts of HTML?
- 09:08:52 [dbaron]
- Anne: If it's in the HTML namespace, then it will have the same special behavior.
- 09:09:17 [dbaron]
- Anne: ... if it meets all the requirements of being a body (second child of HTML element, or something...).
- 09:10:26 [dbaron]
- Daniel: The BODY is mandatory; you can't remove it.
- 09:10:33 [dbaron]
- David: You can remove it through the DOM.
- 09:12:03 [dbaron]
- (discussion)
- 09:12:21 [dbaron]
- David: We don't want to get into the discussion of what an HTML document is for the DOM.
- 09:12:56 [dbaron]
- Steve: If it's invalid, then interoperability is irrelevant.
- 09:13:09 [dbaron]
- Anne: You're confusing authoring requirements and user-agent requiremnets.
- 09:15:06 [dbaron]
- (discussion of HTML and DOM issues)
- 09:15:58 [dbaron]
- s/requiremnets/requirements/
- 09:21:03 [dbaron]
- Alex: Any concern about describing behavior of invalid documents?
- 09:21:14 [dbaron]
- Anne: Not at all unusual... e.g., style sheets missing closing }
- 09:22:17 [dbaron]
- Daniel: I abstain (no objection).
- 09:22:26 [dbaron]
- Anne, Elika, David, Alex: in favor
- 09:23:23 [dbaron]
- Anne: We should separate user-agent requirements and authoring requirements.
- 09:23:27 [dbaron]
- (in response to comment by Alex)
- 09:23:31 [dbaron]
- Daniel: ok, resolved.
- 09:23:57 [anne]
- http://www.w3.org/Style/css2-updates/issues-4-20061106.html#issue-31
- 09:24:06 [dbaron]
- RESOLVED: accept proposal in http://www.w3.org/Style/css2-updates/issues-4-20061106.html#issue-31
- 09:27:23 [dbaron]
- http://lists.w3.org/Archives/Public/www-style/2007Mar/0035.html
- 09:28:20 [Zakim]
- Zakim has left #css
- 09:28:55 [fantasai]
- http://wiki.csswg.org/spec/css2.1#issue-80
- 09:29:16 [dbaron]
- (Were we accepting the 17.5 changes as well?)
- 09:31:13 [fantasai]
- http://wiki.csswg.org/spec/css2.1#issue-79
- 09:31:59 [dbaron]
- RESOLVED: accept proposal in http://www.w3.org/Style/css2-updates/issues-4-20061106.html#issue-31 (chapters 11 and 14 parts)
- 09:32:23 [dbaron]
- Topic: Margin collapsing (issue 79)
- 09:33:00 [dbaron]
- Alex: When min-height has an effect, it prevents the bottom margin of the element from collapsing with the bottom margin of its last child.
- 09:33:05 [dbaron]
- Alex: What exactly does this mean?
- 09:34:02 [dbaron]
- Alex: Does it mean that the element's height is exactly the min-height, or bigger?
- 09:34:10 [fantasai]
- ScribeNick: fantasai
- 09:34:17 [fantasai]
- Alex draws a blue rectangle.
- 09:34:27 [fantasai]
- Alex: Here we have a parent with some margin, and it has a child with some other margin
- 09:34:32 [fantasai]
- Alex draws a short margin below the blue box
- 09:34:47 [fantasai]
- Alex draws a red box inside the blue box, with a large margin that extends outside the box
- 09:35:42 [fantasai]
- Alex: If the height was not specified, the parent would be as big as its child, and their margins would collapse, and the box after it (Alex draws a green box below the margin)
- 09:35:47 [fantasai]
- would be after the collapsed margin.
- 09:36:05 [fantasai]
- Alex: What's going to happen if we add a min-height that is bigger than the natural height?
- 09:36:16 [fantasai]
- Alex: The parent box would grow
- 09:36:27 [fantasai]
- Alex: but the margins no longer collapse
- 09:36:33 [fantasai]
- s/margins/bottom margins/
- 09:36:40 [fantasai]
- Alex: What happens to the margins?
- 09:36:44 [fantasai]
- Alex: We have two options
- 09:36:53 [fantasai]
- Alex: We treat the min-height as height,
- 09:37:05 [fantasai]
- Alex: which causes us to ignore the bottom margin of the child
- 09:37:20 [fantasai]
- Alex: which means the effective margin is much smaller than before, and the green box moves higher
- 09:38:10 [fantasai]
- Alex: the other option is for the child's margin to be included in the parent's content box
- 09:38:27 [fantasai]
- Alex: so the parent box grows bigger than the min-height in order to contain the margin
- 09:38:41 [fantasai]
- Alex: and this is another interpretation of not collapsing the margins
- 09:39:00 [fantasai]
- Alex: I have two options here. I could go with Firefox's behavior (the former) which is the easiest to implement
- 09:39:13 [fantasai]
- Alex: Other option is to do the second option, which requires redoing size computation
- 09:39:55 [fantasai]
- David: You'd have a discontinuity
- 09:40:00 [fantasai]
- Elika: You have one in both cases
- 09:40:11 [dbaron]
- http://dbaron.org/css/test/2008/min-height-margin-collapse
- 09:40:15 [fantasai]
- Elika: In FF's case the green box jumps up once min-height takes effect
- 09:41:23 [fantasai]
- We look at dbaron's testcase
- 09:41:32 [fantasai]
- Alex: In this case it can become 200px or 400px
- 09:41:40 [fantasai]
- Alex: That would be the difference between the different options
- 09:42:32 [fantasai]
- Alex: Once the bottom margin doesn't collapse anymore, then you lose the distance between the bottom of this box and the next box
- 09:42:32 [glazou]
- (observer is Hartmut Glaser from NIC.br)
- 09:43:02 [fantasai]
- David: It seems to me that it should be 200px high but you should have a 200px margin as well
- 09:44:01 [fantasai]
- Elika: That wouldn't make sense if the parent's min-height would contain its child including its margin
- 09:45:10 [fantasai]
- Peter: What I don't want to see is the margin collapsing of the child change behavior based on whether the min-height is applying in this scenario...
- 09:45:25 [fantasai]
- Peter actually said something about large margins appearing and disappearing mysteriously
- 09:45:31 [fantasai]
- when you hit a discontinuity point
- 09:46:05 [fantasai]
- ...
- 09:46:39 [fantasai]
- David: In Oslo in 2003 we rewrote margin collapsing, and I didn't like that we introduced a discontinuity. We had a big discusison on how clearance, margin collapsing, and height computation
- 09:46:43 [fantasai]
- interact
- 09:47:52 [fantasai]
- Peter: If the height of an elemetn depends on the viewport width and resizing the window causes a giant margin to appear and disappear, nobody is going to be happy with that result
- 09:48:41 [fantasai]
- Alex: So I think we should include the margin in the parent's height
- 09:49:14 [fantasai]
- Steve: I realize the agreements reached in Oslo are very fragile, would doing what Alex says break those agreements?
- 09:49:29 [fantasai]
- David: No
- 09:50:26 [fantasai]
- Anne: So it seems all browsers are doing different things
- 09:53:25 [fantasai]
- ....
- 09:54:43 [fantasai]
- Alex: we could do Opera's solution (collapse the bottom borders even in the presence of min-height)
- 09:55:00 [fantasai]
- Elika: That would not make sense if the min-height is big enough to contain the margin
- 09:55:45 [fantasai]
- Alex: but its behavior is continuous
- 09:56:15 [fantasai]
- Discussion about what is intuitive
- 09:56:23 [fantasai]
- Steve: It really bothers me that we don't have any designers here
- 09:57:15 [fantasai]
- Steve: At least Alex's proposal is consistent with what happens when margin collapsing is turned off elsewhere
- 09:58:05 [fantasai]
- David: I think from a designer's pov parent-child margin collapsign was a mistake
- 09:58:13 [fantasai]
- Peter: There are cases where it makes esnes from a designer's pov
- 09:59:00 [fantasai]
- Peter: what doesn't make sense is the margin collapsing turning on and off for inexplicable reasons
- 09:59:44 [fantasai]
- ...
- 10:00:20 [fantasai]
- Peter: The margin of a box should not begin somewhere far below the box, it should always be attached
- 10:00:31 [fantasai]
- Elika: You're asking for partial collapsing
- 10:00:39 [fantasai]
- David: THat's what we decided never to do in Oslo
- 10:01:11 [fantasai]
- ...
- 10:01:23 [fantasai]
- Alex: Let's suppose the next element has a top margin of 300px, what will that margin collapse with?
- 10:01:40 [fantasai]
- Steve: It shouldn't make any difference, it will collapse with the collapsed result of what we get here
- 10:03:08 [fantasai]
- Steve tries to explain the margin collapsing model
- 10:04:40 [fantasai]
- Bert: What about when we introduce vertical-alignment?
- 10:04:58 [fantasai]
- Elika: We decided that that would create a new block formatting context, then you wouldn't collapse the parent and child margins
- 10:06:16 [fantasai]
- Alex: ... partial collapsing
- 10:06:23 [glazou]
- (sorry for the phone call, it's was my plumber, and no his name is NOT Joe :-)
- 10:06:45 [fantasai]
- Bert: That was the original intention, that you take the lowest of the bottom of the relevant margins
- 10:07:22 [fantasai]
- Anne: Is it really worth making margin collapsing that much more complicated?
- 10:09:15 [fantasai]
- discussion of usage of margins
- 10:09:40 [fantasai]
- Margin collapsing is designed not for layout, but for when you have a continuous flow of content: headings, paragraphs, etc
- 10:10:11 [fantasai]
- Elika; We have several options here, let's list them
- 10:10:24 [fantasai]
- A. Firefox's behavior, which to truncate to min-height
- 10:10:35 [fantasai]
- and ignore the child margin
- 10:10:56 [fantasai]
- B. Alex' 1st proposal, which is to growt include the child and min-height
- 10:11:28 [fantasai]
- C. Opera behavior: collapse margins, then apply min-height
- 10:11:34 [fantasai]
- D. Define partial collapsing
- 10:12:36 [fantasai]
- David: I don't think it's really partial collapsing that you want to define, it's putting the edge of an element in the middle of a margin collapse
- 10:12:47 [fantasai]
- David: But that's really a huge change at this point
- 10:12:56 [fantasai]
- Steve: Are there other cases where this happens?
- 10:13:04 [fantasai]
- David, Bert: THere are other cases with clear where something like this happens.
- 10:13:15 [fantasai]
- David: THe concept of clearance was created in the discussion I'm talking about
- 10:13:40 [fantasai]
- David: Before 2003 clearance didn't exist, clear just added a margin which then collapsed
- 10:14:15 [dbaron]
- It's not really partial collapsing -- it's making the top/bottom edge of an element be in the middle of its margin
- 10:14:30 [dbaron]
- but that's what we decided to avoid in 2003.
- 10:14:50 [fantasai]
- Alex: but floats...
- 10:15:03 [fantasai]
- David: We ended up saying that the position of a float can be in one of these places
- 10:15:12 [dbaron]
- To be clear, I really don't want to change the big stuff (i.e., go with (D)) at this point.
- 10:16:04 [fantasai]
- Elika: Do we have consensus on eliminating D?
- 10:16:27 [fantasai]
- Steve: No, because that's what would make the most sense from a designer's perspective
- 10:17:01 [fantasai]
- Alex: Min-height is as currently specified has a side-effect on margin collapsing that is not intuitive to the designer
- 10:17:17 [fantasai]
- Steve: I'm trying to think of reasons why a designer would set min-height
- 10:17:31 [fantasai]
- Alex: Let's try to come up with examples
- 10:17:50 [fantasai]
- Alex: maybe I have business cards, and I set min-width min-height to 2/3
- 10:18:04 [fantasai]
- Alex: so if someone's card has more info at least it shows
- 10:18:33 [fantasai]
- Steve: in that case I wouldn't want the child margins to spill outside the box
- 10:19:35 [fantasai]
- Alex: Say I have a series of paragraphs and a div around some of them
- 10:20:01 [fantasai]
- Alex: Don't want setting min-height to make the margins between the apragraphs to disappear
- 10:20:12 [dbaron]
- E. Say min-height != 0 always prevents collapsing.
- 10:21:27 [fantasai]
- Daniel: I use min-height all the time.
- 10:21:42 [fantasai]
- Daniel: I have a <pre>, and I want a minimum height for my code box
- 10:22:30 [dbaron]
- Designers aren't really using min-height in the wild because of IE support, I think.
- 10:24:20 [fantasai]
- everybody has a different idea of what designers would want for min-height and margin collapsing
- 10:24:30 [fantasai]
- fantasai posts to twitter and gives up trying to minute
- 10:25:45 [fantasai]
- Discuss dbaron's option E
- 10:25:57 [fantasai]
- Alex: That's what IE8 impelements, and I'm not convinced it's more intuitive
- 10:26:23 [fantasai]
- Alex: Min-height normally doesn't have any effect when the min-height is very small
- 10:28:21 [fantasai]
- David: Using min-height along with an auto height has two uses
- 10:28:58 [fantasai]
- David: You're sayin to use the maximum of the content height and the given min-height
- 10:29:09 [fantasai]
- David: We dont' know which is going to be the normal case, it's different fro different uses
- 10:29:33 [anne]
- (in the case where you really want to use the margin of the parent you just use parent > :last-child { margin-bottom:0 } )
- 10:29:36 [fantasai]
- in some cases your base case using the content height, and the min-height is an exception
- 10:30:13 [fantasai]
- and in other cases your base case is the min-height, and the content height is the exception (for when there's too much content)
- 10:30:28 [fantasai]
- fantasai thinks that david baron's point here is really important!!!
- 10:34:51 [dbaron]
- So one other question is whether we want there to be differences between "height: auto; min-height: 200px" and "min-height: min-content; height: 200px"
- 10:40:00 [fantasai]
- Steve: We remove the line that says min-height turns margin collapsing off.
- 10:40:21 [fantasai]
- Steve: Then we still have the question of how margin collapsing behaves when it's on and min-height has an effect
- 10:41:28 [fantasai]
- RESOLVED: min-height does not turn off margin collapsing
- 10:41:39 [fantasai]
- fantasai is skeptical and reserves judgement
- 10:43:16 [fantasai]
- LUNCH
- 11:46:51 [jdaggett]
- jdaggett has joined #css
- 11:54:23 [MoZ]
- MoZ has joined #css
- 11:59:31 [shepazu]
- shepazu has joined #css
- 12:00:39 [jdaggett]
- shepazu: http://wiki.csswg.org/planning/mandelieu-2008
- 12:02:37 [shepazu]
- thanks, jdaggett
- 12:04:22 [plinss_]
- plinss_ has joined #css
- 12:06:17 [glazou]
- glazou has joined #css
- 12:07:37 [sylvaing]
- sylvaing has joined #css
- 12:09:58 [SteveZ]
- SteveZ has joined #css
- 12:11:39 [SteveZ]
- This is a test
- 12:12:04 [fantasai]
- ScribeNick: SteveZ
- 12:12:09 [dbaron]
- dbaron has joined #css
- 12:12:45 [SteveZ]
- Issue: CSS2.1 issue 60 - Z index
- 12:12:45 [trackbot]
- Created ISSUE-68 - CSS2.1 issue 60 - Z index ; please complete additional details at http://www.w3.org/Style/CSS/Tracker/issues/68/edit .
- 12:12:45 [fantasai]
- Elika: Issue #60 is that Appendix E conflicts with chapter 9 in the CSS2.1 text
- 12:15:08 [fantasai]
- http://dev.moonhenge.net/css21/spec/z-index/
- 12:15:48 [SteveZ]
- Start with 2.1. Stacking context–like behaviour
- 12:16:00 [dbaron]
- s/Issue:/Topic:/
- 12:20:48 [SteveZ]
- This topic is postponed until tomorrow
- 12:21:13 [SteveZ]
- so that Hixie can participate
- 12:22:29 [SteveZ]
- Topic: Value pseudo attribute
- 12:23:39 [SteveZ]
- DB: this came out of discussion on WhatWG list
- 12:24:18 [SteveZ]
- DB: there was a proposal to have text (specially identified) that can be typed over
- 12:24:43 [SteveZ]
- DB: Styling should specify how that text is specially identified
- 12:25:01 [SteveZ]
- DB: this is attribute like, but not actually an attribute
- 12:25:19 [SteveZ]
- AvK: This is sort of like a DOM attribute
- 12:25:46 [SteveZ]
- AvK: it seems to apply to placeholders
- 12:26:07 [SteveZ]
- DB: you could combine it with the focus selector
- 12:26:31 [fantasai]
- http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016544.html
- 12:26:34 [anne]
- WebKit has implemented :-webkit-placeholder for this case. That works for focusing the input control as well and such.
- 12:26:59 [dbaron]
- http://lists.w3.org/Archives/Public/www-style/2008Oct/0144.html
- 12:27:11 [dbaron]
- but it would actually need input[:value=""]:not(:focus)
- 12:27:24 [SteveZ]
- DG: I was wrong to complain that it would be difficult to internationalize because this applies only to the content of an attribute
- 12:28:24 [SteveZ]
- AvK: When this facility (sample text) is added to HTML, then having a placeholder pseudo element would make sense
- 12:30:49 [SteveZ]
- BB: I find that having the placeholder disappear when a partial selection is done disturbing; I want to be able to select the text and cut it and paste it
- 12:31:33 [SteveZ]
- BB: the above point is really an HTML not a CSS point
- 12:31:45 [fantasai]
- Topic: Selectors
- 12:32:35 [SteveZ]
- Does the current Hover element apply to the parent if the child is outside of the display space of the parent
- 12:33:22 [fantasai]
- http://www.w3.org/Style/CSS/Tracker/issues/65
- 12:34:03 [anne]
- test
- 12:34:03 [SteveZ]
- DG: e.g. a child element is relatively positioned outside its structural parent
- 12:34:03 [anne]
- http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cstyle%3E%20div%3Ahover%20%7B%20background%3Ayellow%20!important%20%7D%20%3C%2Fstyle%3E%0D%0A...%3Cdiv%20style%3Dheight%3A50px%3Bwidth%3A50px%3Bbackground%3Alime%3E%0D%0A%3Cdiv%20style%3Dheight%3A50px%3Bwidth%3A50px%3Bbackground%3Ared%3Bposition%3Aabsolute%3Btop%3A40px%3Bleft%3A100px%3E%3C%2Fdiv%3E%0D%0A%3C%2Fdiv%3E
- 12:34:11 [anne]
- (that test tests the behavior)
- 12:34:16 [anne]
- (being discussed)
- 12:34:53 [SteveZ]
- DG: all browsers do selection of the parent
- 12:35:53 [SteveZ]
- AM: I have an example where I show help text outside the button to which it applies and I want the hover to stay on if the cursor moves over the help text
- 12:36:32 [SteveZ]
- AvK: There are other examples which depend on this behavior
- 12:37:24 [SteveZ]
- DG: I want to be sure that the specification will make clear what a user should expect; in particular, that it is not just the physical position of the cursor that triggers hover behavior.
- 12:37:48 [SteveZ]
- DG and EE: this probably needs a note in the spec
- 12:38:33 [SteveZ]
- DB: you figure out which element would receive the event and that element and all its ancestors are in the hover state
- 12:39:29 [SteveZ]
- DB: you have to keep compatibility with hovering over a link or any of its descendents will keep the link in the hover state
- 12:40:37 [SteveZ]
- PL: we should define the hover processing in terms of event processing and accept that the specs that define event processing will say what elements are affected
- 12:41:43 [SteveZ]
- DB: the behavior of events on hidden elements is not consistent across browsers
- 12:42:15 [SteveZ]
- DB: SVG has a property called "pointer events" that may make sense to adopt at some point
- 12:42:57 [SteveZ]
- DB: right now this is massively undefined in the selector spec; I would favor more specification as would PL
- 12:43:52 [SteveZ]
- AvK: Say when the element is in "the hover state" (as defined by some spec) then the behavior is ....
- 12:44:13 [SteveZ]
- DB and EE: but is there a spec that defines "the hover state"
- 12:45:00 [SteveZ]
- DB: We can define things in terms of DOM level 2 events (a REC)
- 12:46:29 [SteveZ]
- DB: we are leaving the hit testing definition to some other spec, but we can define the rest now
- 12:46:52 [SteveZ]
- DB: why are we changing only hover and not "active"
- 12:47:11 [SteveZ]
- EE: "active" is not well defined
- 12:47:50 [SteveZ]
- EE: in IE an element remains active even after a click is released
- 12:47:59 [SteveZ]
- AM: this works on the iPhone
- 12:48:33 [SteveZ]
- PL: thie activity persists during a load, but not forever.
- 12:49:18 [SteveZ]
- DB: does it matter that browsers have different behaviors for "active"
- 12:49:30 [SteveZ]
- EE: the differences are so subtle that it is OK
- 12:50:27 [SteveZ]
- DB: I am OK with differing when something begins being active and ends being active, but not with not saying whether the ancestors are active or not
- 12:51:28 [SteveZ]
- EE: I would say that "active" does not propogate up; e.g. clicking on something (a span) inside an anchor makes only the span active
- 12:51:33 [anne]
- data:text/xml,<html xmlns="http://www.w3.org/1999/xhtml"><style> a:active { background:lime }</style><a href="test">a<a href="test">b<a href="test">c</a></a></a></html>
- 12:52:18 [SteveZ]
- AvK: active only applies to the element being activated is active, but in Mozilla and Webkit the ancestors are active as well
- 12:52:55 [SteveZ]
- AvK: I thnk that in Firefox, nested links have some anomolies in behavior
- 12:53:45 [SteveZ]
- EE: CSS does not define what elements get activated or for how long
- 12:54:38 [fantasai]
- or what triggers the activation
- 12:55:09 [SteveZ]
- DB: current spec says "while it is being activated" not "while it is active".
- 12:55:33 [fantasai]
- EE: e.g. clicking on something (a span) inside an anchor makes only the *anchor* active (not the span)
- 12:56:04 [fantasai]
- EE: and clicking on a triple-nested link should only apply :active to the link that's been activated
- 12:56:20 [SteveZ]
- DB: not sure that this is something that should be defined differently in different specs
- 12:56:50 [shepazu]
- SCXML and the SMIL State module define state (but I don't know if they are compatible with each other, much less what CSS would mean by "state")
- 12:56:52 [SteveZ]
- DS: (Doug Schepers): there are two specs that define states: SMIL and an SVG spec
- 12:57:09 [shepazu]
- s/SVG spec/MMI spec/
- 12:57:13 [dbaron]
- ScribeNick: dbaron
- 12:57:39 [dbaron]
- EE: So we want text for the :hover issue.
- 12:57:49 [glazou]
- s/we/I
- 12:58:22 [dbaron]
- EE: I'm ok with saying that the parent of an element that's :active is not necessarily :active, but that :hover is propagated to ancestors.
- 12:58:58 [anne]
- data:text/xml testcase as link http://annevankesteren.nl/test/css/temp/003.xml
- 13:00:22 [dbaron]
- BB: Leave it undefined for :active because we don't know what elements can be activated.
- 13:00:44 [anne]
- So I said that Opera activates the innermost link, where Firefox activates the outermost
- 13:00:45 [dbaron]
- DB: ?
- 13:00:52 [dbaron]
- DG: The original issue was just this one clarification.
- 13:00:59 [dbaron]
- DB: But it was a clarification about something that's explicitly undefined.
- 13:01:05 [dbaron]
- ScribeNick: SteveZ
- 13:01:13 [anne]
- And that what Opera does is currently specified in HTML5 and probably matches what IE does (you can test using submit buttons and links)
- 13:01:29 [SteveZ]
- BB: if an ancestor has a hover selector does that block propogation?
- 13:01:55 [SteveZ]
- PL: no, the existance of selectors is indpendent of event propogation
- 13:02:43 [SteveZ]
- BB: if you have two ancestors with pop-ups on hover, you will get both unless the first one blocks propogation
- 13:03:54 [fantasai]
- proposal: t
- 13:04:04 [fantasai]
- If an element that is ':hover' causes its parent to
- 13:04:04 [fantasai]
- be in ':hover', then it is possible for an element that is not underneath
- 13:04:05 [fantasai]
- the pointing device is in ':hover'.
- 13:05:27 [fantasai]
- If an element that is ':hover' causes its parent to
- 13:05:27 [fantasai]
- be ':hover', then it is possible for an element that is not underneath
- 13:05:27 [fantasai]
- the pointing device to be ':hover'.
- 13:06:19 [glazou]
- if :hover applies to an element causes :hover apply to the parent element, then it's possible :hover applies to an element that is not underneath the pointing device
- 13:08:53 [SteveZ]
- BB: the typical use case for "hover" is to indicate what can be activated so only the things that can be activated should be in hover; not all ancestors
- 13:08:53 [fantasai]
- If it's possible for ':hover' to apply to an element because its
- 13:08:53 [fantasai]
- child is designated by a pointing device, then it's possible for
- 13:08:53 [fantasai]
- ':hover' to apply to an element that is not underneat the pointing
- 13:08:53 [fantasai]
- device.
- 13:08:58 [fantasai]
- If it's possible for ':hover' to apply to an element because its
- 13:08:58 [fantasai]
- child is designated by a pointing device, then it's possible for
- 13:08:58 [fantasai]
- ':hover' to apply to an element that is not underneat the pointing
- 13:08:58 [fantasai]
- device.
- 13:10:20 [SteveZ]
- DB: the WG did not resolve that hover was heirarchical but with IE8 all implementations seem to make it hierarchical
- 13:10:45 [SteveZ]
- N.B. the above text by fantasai is intended as a NOTE
- 13:11:03 [fantasai]
- checked in
- 13:11:33 [fantasai]
- RESOLVED: proposal above accepted
- 13:11:57 [dbaron]
- http://dbaron.org/css/test/sec051103b is a testcase for hierarchical :hover
- 13:12:19 [dbaron]
- (and :active)
- 13:12:35 [SteveZ]
- Topic: Grammer for an+b for nth child
- 13:15:42 [SteveZ]
- DG: although whether hover applies to ancestors is officially undefined; millions of websites would break if it were otherwise defined
- 13:16:23 [shepazu]
- I'd just like to note that you could define "hovered" as being defined by the host language
- 13:16:40 [glazou]
- http://www.w3.org/Style/CSS/Tracker/issues/66
- 13:16:44 [shepazu]
- then it's out of the CSS's problem
- 13:17:06 [shepazu]
- s/out of /not /
- 13:19:28 [dbaron]
- You want the n, the even, and the odd to be written using the {n}, {o}, etc. productions from the grammar
- 13:19:35 [SteveZ]
- EE: we had already resolved where white space is allowed: not between a unary operator and the integer to which it applies nor between the integer and the "n"
- 13:19:53 [dbaron]
- and it would be nice to indent so the [] and () don't line up with the | because they look a lot like |
- 13:20:06 [SteveZ]
- DB: the odd and even need to be case insensitive
- 13:20:56 [SteveZ]
- DG: the 'n' is escapable, but not the "+" or "-"
- 13:21:04 [dbaron]
- (since units are escapable, but sign is not... right?)
- 13:21:47 [SteveZ]
- Resoved: the proposed grammer is accepted, with the modification to allow the 'n' is escapable.
- 13:21:56 [fantasai]
- s/Resolved/RESOLVED/
- 13:22:13 [SteveZ]
- Topic: ::selectors
- 13:22:28 [dbaron]
- Ah, so we haven't had the pseudo-element argument for a few years, so we need to do it again...
- 13:22:58 [fantasai]
- http://www.w3.org/Style/CSS/Tracker/issues/67
- 13:25:24 [fantasai]
- ScribeNick: fantasai
- 13:25:36 [fantasai]
- David: Pseudo-elements have this thing where their boundaries don't line up with the tree
- 13:25:56 [fantasai]
- David: The question is do you split the <span> into 2 pieces, or do you split the pseudo-element into 2 pieces?
- 13:26:06 [fantasai]
- David: The current spec says you split the pseudo-element
- 13:26:23 [SteveZ]
- DB: pseudo elements have boundaries that do not necessarily match the boundaries of the mark-up; which is split: the pseudo element or the real element?
- 13:26:28 [fantasai]
- Daniel: Can the pseudo-element contain more than pcdata and replaced elements?
- 13:26:38 [fantasai]
- Peter: you could have a selection, for example in the example in 67
- 13:27:14 [fantasai]
- Peter: you can't contain the children and still be well-formed
- 13:27:15 [alexmog]
- alexmog has joined #css
- 13:27:17 [dbaron]
- The question is: Does <span>A<pseudo>B</span>C</pseudo> give the tree <span>A<pseudo>B</pseudo></span><pseudo>C</pseudo> or <span>A</span><pseudo><span>B</span>C</pseudo>?
- 13:27:42 [fantasai]
- Peter: the HTML5 spec might say something about this, wrt malformed markup
- 13:28:14 [fantasai]
- Peter: In this scenario, what you get with the pseudo-element should always be describable as valid tree markup
- 13:28:27 [fantasai]
- Daniel: It's describable as a DOM range
- 13:28:35 [anne]
- ls
- 13:28:42 [anne]
- sorry about that
- 13:28:43 [fantasai]
- David: The problem is that many CSS properties, including inheritance, are defined in terms of a tree
- 13:29:17 [fantasai]
- Daniel: Question remains, do I have multiple outlines for richtext::selection?
- 13:29:55 [fantasai]
- ...
- 13:30:10 [fantasai]
- David: What Mozilla actually implements now, I think, is something that sounds even more complicated than these two
- 13:30:15 [fantasai]
- David: We do both
- 13:30:24 [fantasai]
- David: We do one for the inherited properties and one for the non-inherited properties
- 13:30:40 [SteveZ]
- DB: Mozilla implements that 3rd option: it treats the inherited and non-inherited properties
- 13:30:49 [fantasai]
- Daniel: I wonder if we should just remove outline from the list of properties allowed?
- 13:30:51 [SteveZ]
- differently
- 13:31:45 [fantasai]
- David: I'm not even sure if that's quite what we do
- 13:31:53 [anne]
- http://annevankesteren.nl/test/css/temp/004.xml
- 13:31:55 [fantasai]
- Anne: Opera doesn't apply outline at all
- 13:32:06 [SteveZ]
- BB: in David's solution "outline" is an outer thing so goes around the whole thing and "color" is an inner thing so it would be inside the markup elements
- 13:36:47 [fantasai]
- Anne: It seems nobody implements outline
- 13:40:15 [dbaron]
- Peter: What about p::selection { color: inherit } ?
- 13:42:10 [mollydotcom]
- mollydotcom has joined #css
- 13:42:44 [SteveZ]
- DB: Warning: at some point I may want to propose styling of multiple ranges
- 13:43:14 [SteveZ]
- DB: "background" is non-inherited so its behavior would be the same as that for "outline"
- 13:43:28 [dbaron]
- I think for ::selection it's important that the ::selection is innermost for the 'color'.
- 13:44:58 [SteveZ]
- AvK: if there is a span::selecction it should apply; it does in Opera but not in Firefox
- 13:45:56 [dbaron]
- With ::selection, do you ever get <p::selection><span::selection>sel</span::selection></p::selection>, or something else?
- 13:46:04 [glazou]
- hey mollydotcom!!!!
- 13:46:10 [mollydotcom]
- greetings all
- 13:46:15 [dbaron]
- and how do global ::selection styles interact with that?
- 13:46:43 [mollydotcom]
- catching up on the topic, having tea to wake up, be with you all in a bit
- 13:47:01 [fantasai]
- David: Suppose you have a selection that includes an element that is 20 levels nested
- 13:47:10 [dbaron]
- If you have a ::selection{} rule and your selection is in an element 20 levels nested within the tree, and your background color is rgba(255, 0, 0, 0.2), what happens?
- 13:47:13 [dbaron]
- Do you have 20 pseudos?
- 13:48:02 [fantasai]
- If you have p::selection and you set a color on it
- 13:48:16 [fantasai]
- And you have a span inside the p, you want the selection inside the span to have the color you set on p::selection
- 13:49:26 [fantasai]
- (that was dbaron, btw, not me)
- 13:49:39 [fantasai]
- David: So this is not a tree-based approach. How do you deal with inheritance?
- 13:49:45 [dbaron]
- p::selection { color: blue } span { color: purple; }
- 13:49:59 [dbaron]
- <p>Text << text <span>span</span> text >> text.</p>
- 13:50:18 [dbaron]
- we want the "span" to be blue rather than purple
- 13:52:03 [dbaron]
- We definitely don't want to distinguish "in the selection" from "contains the selection" because it can be half and half.
- 13:52:18 [dbaron]
- What about 'color: inherit' ?
- 13:54:15 [fantasai]
- Peter points out that Daniel's concept of a global selection is incompatible with the idea of styling p::selection and span::selection differently
- 13:55:18 [fantasai]
- Steve: A selection is a set of DOM ranges.
- 13:55:30 [fantasai]
- Steve: That's the One Selection
- 13:55:37 [fantasai]
- Steve: Then there's the issue of how to style it
- 13:55:47 [fantasai]
- Steve: THe proposal is to style it as if the selection is not there
- 13:55:58 [fantasai]
- Steve: Then go back and for the pieces that fall into the range, you restyle them
- 13:56:15 [fantasai]
- Anne: That's not desired for the span case because then p::selection would not apply to the span nested inside the p
- 13:58:39 [fantasai]
- David: I think it would help to have concrete examples
- 13:59:29 [SteveZ]
- DG: I will come up with a list of requirements for what ::selection should and should not do
- 13:59:49 [SteveZ]
- DG: one requirement is that we do not want nested outlines
- 14:00:03 [SteveZ]
- DG: we want color to nest locally
- 14:01:26 [SteveZ]
- ACTION: (DG) develop requirements for ::selection behavior
- 14:01:26 [trackbot]
- Sorry, couldn't find user - (DG)
- 14:01:57 [Bert]
- How about: insert <::selection> at the start, </::selection> before every tag, <::selection> after every tag, and </::selection> at the end: <p>...........<<<<::>.......</::></p><::> </::><p><::>......</::><span><::>......</::>>>>.......</span></p>
- 14:01:57 [dbaron]
- http://dbaron.org/css/test/sec051103b is a testcase for hierarchical :hover
- 14:02:01 [Bert]
- (and then think about 'outline' separately)
- 14:02:19 [SteveZ]
- ACTION:glazou, develop requirements for ::selection behavior
- 14:10:06 [mollydotcom]
- I look at this and try to imagine designers having a clue. It isn't working.
- 14:13:34 [mollydotcom]
- just bear in mind designers want very explicit control of every piece within a given selection
- 14:27:51 [SteveZ]
- This is a test
- 14:29:25 [SteveZ]
- SteveZ has joined #css
- 14:29:55 [SteveZ]
- WG resumes at 4:30PM
- 14:30:43 [SteveZ]
- Topic: First line, First letter pseudoelements
- 14:30:51 [glazou]
- http://lists.w3.org/Archives/Public/www-style/2006Jan/0209.html
- 14:33:25 [sylvaing]
- sylvaing has joined #css
- 14:33:50 [anne]
- anne has joined #css
- 14:33:59 [glazou]
- http://lists.w3.org/Archives/Public/www-style/2006Jan/0091.html
- 14:34:47 [fantasai]
- David: I think this is what we solved by doing the inherited/non-inherited properties split
- 14:35:08 [fantasai]
- David: He put a display property on the :first-line and then display:inhert on a span in the first line
- 14:35:31 [glazou]
- http://lists.w3.org/Archives/Public/www-style/2005Oct/0163.html
- 14:35:32 [dbaron]
- http://lists.w3.org/Archives/Public/www-style/2005Oct/0163.html
- 14:36:03 [fantasai]
- David: What we used to do on this test case was crash
- 14:39:18 [fantasai]
- David looks up what exactly Mozilla does here
- 14:41:50 [fantasai]
- David: If you have property: inherit; on an element that is inside the :first-line, then we don't inherit from the :first-line
- 14:42:39 [fantasai]
- David: for non-inherited properties
- 14:43:23 [fantasai]
- David: The effective change for this is only when the 'inherit' keyword is used on a non-inherited property
- 14:43:51 [fantasai]
- David: That's a very uncommon case
- 14:44:07 [fantasai]
- David: It's possible we want to change the behavior on more common cases
- 14:44:21 [fantasai]
- David: like a tiled background image on ::first-line
- 14:45:18 [fantasai]
- David reviews the spec
- 14:45:29 [fantasai]
- David: no, that's should probably work...
- 14:48:07 [fantasai]
- David: So how should we be changing the spec to try to address this?
- 14:48:14 [SteveZ]
- DG: The current spec says that the span is split into two separate boxes
- 14:48:26 [glazou]
- s/DG/DB ?
- 14:48:46 [SteveZ]
- DG: How should the spec be changed to allow/require what Mozilla does?
- 14:48:47 [fantasai]
- David: Do we want to say what Mozilla does with inheritance is allowed, or required, or it's undefined, or make another change
- 14:49:00 [fantasai]
- Alex: IE does exactly what Mozilla does at this point.
- 14:49:19 [SteveZ]
- AM: it appears that IE does what Mozilla does at this point
- 14:49:20 [fantasai]
- Alex: inheritance comes not from the pseudo-class but from the actual parent
- 14:49:35 [fantasai]
- David: but for an inherited property like color?
- 14:49:40 [fantasai]
- Alex: doesn't inherit
- 14:49:49 [SteveZ]
- s/DG/DB/
- 14:50:38 [fantasai]
- David inspects Alex's testcase
- 14:51:59 [Bert]
- (Is it the case that proeprties that don't apply to :first-line are also not inherited from :first-line? Or are only non-inherited properties not inherited?)
- 14:52:15 [fantasai]
- only non-inherited properties are not inherited
- 14:53:20 [SteveZ]
- DB: explicit inheritance of non-inherted properties ignores the firstline and firstchar properties in computed the inherited value
- 14:54:42 [SteveZ]
- DB: inheritence of inherited properties do use the properties of firstline where relevant
- 14:58:18 [SteveZ]
- EE: the split between non-inheritable properties do not inherit from the pseudo element properties and inheritable properties do inhert makes sense
- 14:58:40 [SteveZ]
- AM: background and text decoration are safe to inherit
- 14:59:03 [SteveZ]
- BB and DB: position and float are not safe to inherit
- 14:59:54 [SteveZ]
- DB: if you set "whitespace: nowrap" this may change the firstline behavior (beyond just the inheritance question).
- 15:01:10 [SteveZ]
- BB: The keyworld inherits from either the parent of the first line or the firstline; which should be used?
- 15:01:40 [SteveZ]
- BB: one rule might be to inherit from the firstline if the property is applicable to the firstline and the parent otherwise.
- 15:08:12 [SteveZ]
- suggested text: The portion of a child element that occurs on the first line inherits properties applicable to the firstline pseudo element; for properties not applicable to the firstline pseudo element, the inheritence is from the parent of the first line pseudo element
- 15:10:35 [fantasai]
- s/parent/non-pseuo-element parent/
- 15:10:41 [SteveZ]
- add: The portion of a child element that does not occur on the first line always inherits from the parent of that child.
- 15:11:11 [fantasai]
- RESOLVED: proposal above accepted
- 15:15:07 [SteveZ]
- DB: Firefox does not have the same rules for firstletter because firstletter is not layout based; it is only storage order based
- 15:16:46 [SteveZ]
- Many: but, note that a quote followed by a character whose bidi order is opposite from the context in which the quote occurs may separate the quote and the following letter by the rest of the embedded bidi string
- 15:20:34 [jdaggett]
- jdaggett has joined #css
- 15:20:49 [sylvaing]
- sylvaing has left #css
- 15:21:04 [glazou]
- ======== ADJOURN FOR TODAY ===========
- 15:23:04 [mollydotcom]
- Have some fun tonight for me . . . any good restaurants on the plan?
- 15:23:29 [Bert]
- We were just discussing l'Ermitage du Riou...
- 15:23:59 [mollydotcom]
- Bert: Yes, yes, didn't Peter say he had a little room on that HP credit card? ;)
- 15:24:15 [mollydotcom]
- It's a wonderful restaurant
- 15:25:06 [mollydotcom]
- plinss_ and it's not even officially day one of TP/AC
- 15:25:14 [mollydotcom]
- you gotta be ready for the long haul
- 15:25:15 [mollydotcom]
- hehe
- 15:25:30 [mollydotcom]
- enjoy, enjoy. I will be vicariously enjoying through you
- 15:25:48 [mollydotcom]
- and back as time zones permit
- 17:19:10 [myakura]
- myakura has joined #css
- 20:36:59 [arronei]
- arronei has joined #CSS