W3C home > Mailing lists > Public > www-style@w3.org > November 2008

[CSSWG] Minutes F2F 2008-10-19

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 04 Nov 2008 19:49:03 -0800
Message-ID: <491117AF.30500@inkedblade.net>
To: www-style@w3.org

<glazou> http://wiki.csswg.org/planning/mandelieu-2008
<RRSAgent> logging to http://www.w3.org/2008/10/19-css-irc
* dbaron couldn't hear the observer's name
* anne same here, and i was sitting next to him :/
   <glazou> (observer is Hartmut Glaser from NIC.br)

ScribeNick: dbaron

   Daniel: I just posted wiki URL.  Request to discuss CSS2 system colors
           with another WG, probably tomorrow morning.
   Daniel: Who is attending conflicting meetings?
   Steve: I'm chairing another meeting on Tuesday.
   Anne: I have Web Apps Monday and Tuesday; I'll try to alternate, but
         both don't have an agenda yet.
   Daniel: To those who won't be here Monday/Tuesday, anything you want
           discussed today?
   Anne: I want to attend the cross-WG one listed at the bottom of the
         page ("User control over UI").
   Anne: "Special behavior of BODY" we could do, but it should be trivial.
   Steve: My preference is that things like syntax and selectors occur
          on Tuesday.
   fantasai: Melinda wants paged media on Tuesday.
   Steve: Although I'd prefer paged media not on Tuesday.
   Anne: Dean Jackson wanted to discuss Apple proposals... he's not here now.
   Daniel: maybe Monday
   Anne: We'd like it as well, and Mozilla has implemented parts of it.
   Daniel: <goes rapidly over list of topics>
   Daniel: While everybody is here, we should probably discuss 2 things:
           (1) next f2f meetings

F2Fs next year

   Peter: I'd like 4 2-day meetings.
   fantasai: That's tough for people travelling from far away
   Steve: I think 3 3-day is more practical... especially given travel budgets.
   fantasai: It takes a couple days just to adjust to the new time zone
   Daniel:  What time of year?
   David: One issue we've had the past few years is that we've put the summe
          meeting late in the summer and thus very close to the fall meeting
   Daniel: We could do February, June, November...
   John: Can't confirm for sure, but could do one in Tokyo.
   ?: Sophia-Antipolis in June?
   Bert: My holidays are first half of June.
   Daniel: And TPAC in October/November.
   Daniel: Either Boston or Santa Clara.
   Daniel: Let us know about days that are bad in Feb/Mar and late June.
   fantasai: I can't do second half of March.
   Steve: Week of President's Day (US) can be a good week.
   Daniel: I think Haakon may have offered to host in Oslo...
   Daniel: Tentative plan is Tokyo in Feb/Mar, Sophia-Antipolis in June, TPAC
           in US in Oct/Nov.
   Daniel needs to check school vacation calendar
   Daniel: I'd like to be home 25 Feb.
   Anne: No constraints
   Bert: First 2 weeks of June
   Bert: can't do
   Steve: June is difficult, but I can probably work around it
   Daniel: I prefer after March 2nd
   Alex: MSFT March 18-20 not a good time
   David: I have a weak preference for avoiding US Government holidays
   Peter: no constraints
   John: no constraints
   fantasai: Not second half of March
   Alex: Also SxSW is March 13-22
   Discussing dates in June
   Steve prefers week of 22n-26
   Bert is returning on the 23rd
   fantasai: I can't do May 29-June1
   Daniel: So, target 24-25-26 June 2009
   Daniel: Target for 1st meeting, 2 first weeks of March
   ACTION: glazou email w3c-css-wg with proposed dates and ask for

Web designers as invited experts

   Daniel: Jason Cranford Teague has left the WG
   Daniel: Since his perpsective is exteremely valuable, we wanted to
           propose to keep him as an Invited Expert to the WG
   Daniel: This raises an issue because AOL is the kind of company
           that could join the WG, but they are leaving the WG
   Daniel: Jason was never really representing AOL as much as himself
           and the web designers, so I think it makes sense
   Daniel: I understand from a W3C Process point of view it's difficult,
           but we really need web designers
   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
   John: People who are very hard are people who are technically oriented,
        but ...
   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
   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
   Daniel: Jason says he has time
   Bert: Has to pass Mauro and W3CM. He's clearly an AOL employee
   Bert and Steve want him here, but are concerned about process stuff
   fantasai: Other people?
   Daniel: We already had this discussion... remember failure of CSS 11?
   Daniel: ... strictly speaking, it is difficult to make Jason an official
           Invited Expert
   Daniel: but almost everything we do here is public, so he can still
   Steve: We have to be careful about IPR
   (various discussion)

Margin Collapsing in Vertical Text Mode

   Bert: Was wondering about margin collapsing in vertical
   Bert: If you have a vertical block inside a horizontal one
   Alex: That's a yes-or-no question. In our implementation they do collapse
   David: You'd be making a new block formatting context
   RESOLVED: make a new block formatting context when block direction
             switches, margins outside the bfc do collapse

Special behavior of BODY

   Daniel: Proposal by Simon Pieters is to make the body element in
           XHTML magic just like in HTML.
   Anne: Was partly implemented per spec, marked at risk, implementations
         shifted back.
   David: Originally everyone did what simon is proposing
   David: Then the XHTML WG asked us to make this change, and some browsers
   David: There are two different quirks. One for background, one for overflow
   David: I think Mozilla followed both briefly
   David: Webkit followed one but not the other
   David: So we didn't have two implementations of both
   David: so we marked it at risk
   David: Mozilla, Opera, and Webkit currently treat HTML body and XHTML body
          the same way
   David: And simon has a test suite for this quirk stuff
   fantasai: Can we get these tests in the 2.1 test suite?
   fantasai: Anne, make sure they're in the right format and check them into svn?
   David: HTML5 spec wants HTML and XHTML to be treated the same; don't know
          that it's been discussed in WG.
   Alex: We don't do XHTML yet; would be easiest to not do anything special
         for XHTML.
   Daniel: That sounds like a consensus?
   Bert: I'd rather do the other way around, but...
   Bert: I think it's ugly but it doesn't break anything.
   Daniel: And it helps people who want to convert a Web page from HTML4 to
   Bert: But harder to convert to Docbook or other things.
   Bert: I don't like it, but I don't think it's dangerous, just ugly.
   Peter: I'd almost like to see a way of declaring in CSS that element N
          should have this behavior.
   Anne: Seems too obscure to complicate the language.
   fantasai: Seems like a quirk that we just have to deal with for HTML.
   fantasai: It's there because of backwards-compatibility, not because it's
   Bert: But what happens if people create new formats that reuse parts of
   Anne: If it's in the HTML namespace, then it will have the same special
   Anne: ... if it meets all the requirements of being a body (second child
         of HTML element, or something...).
   Daniel: The BODY is mandatory; you can't remove it.
   David: You can remove it through the DOM.
   David: We don't want to get into the discussion of what an HTML document
          is for the DOM.
   Steve: If it's invalid, then interoperability is irrelevant.
   Anne: You're confusing authoring requirements and user-agent requirements.
   (discussion of HTML and DOM issues)
   Alex: Any concern about describing behavior of invalid documents?
   Anne: Not at all unusual... e.g., style sheets missing closing }
   Daniel: I abstain (no objection).
   Anne, fantasai, David, Alex: in favor
   Anne: We should separate user-agent requirements and authoring requirements.
   (in response to comment by Alex)
   Daniel: ok, resolved.
   <anne> http://www.w3.org/Style/css2-updates/issues-4-20061106.html#issue-31
   RESOLVED: accept proposal in http://www.w3.org/Style/css2-updates/issues-4-20061106.html#issue-31
   <dbaron> (Were we accepting the 17.5 changes as well?)
   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-80
   RESOLVED: accept proposal in http://www.w3.org/Style/css2-updates/issues-4-20061106.html#issue-31
             (chapters 11 and 14 parts)

Margin collapsing (issue 79)

   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-79
   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.
   Alex: What exactly does this mean?
   Alex: Does it mean that the element's height is exactly the min-height, or
ScribeNick: fantasai
   Alex draws a blue rectangle.
   Alex: Here we have a parent with some margin, and it has a child with some
         other margin
   Alex draws a short margin below the blue box
   Alex draws a red box inside the blue box, with a large margin that extends
        outside the box
   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) would be after the collapsed
   Alex: What's going to happen if we add a min-height that is bigger than
         the natural height?
   Alex: The parent box would grow
   Alex: but the bottom margins no longer collapse
   Alex: What happens to the margins?
   Alex: We have two options
   Alex: We treat the min-height as height,
   Alex: which causes us to ignore the bottom margin of the child
   Alex: which means the effective margin is much smaller than before, and
         the green box moves higher
   Alex: the other option is for the child's margin to be included in the
         parent's content box
   Alex: so the parent box grows bigger than the min-height in order to
         contain the margin
   Alex: and this is another interpretation of not collapsing the margins
   Alex: I have two options here. I could go with Firefox's behavior (the
         former) which is the easiest to implement
   Alex: Other option is to do the second option, which requires redoing
         size computation
   David: You'd have a discontinuity
   fantasai: You have one in both cases
   <dbaron> http://dbaron.org/css/test/2008/min-height-margin-collapse
   fantasai: In FF's case the green box jumps up once min-height takes effect
   We look at dbaron's testcase
   Alex: In this case it can become 200px or 400px
   Alex: That would be the difference between the different options
   Alex: Once the bottom margin doesn't collapse anymore, then you lose
         the distance between the bottom of this box and the next box
   David: It seems to me that it should be 200px high but you should have
          a 200px margin as well
   fantasai: That wouldn't make sense if the parent's min-height would
             contain its child including its margin
   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...
   Peter actually said something about large margins appearing and
         disappearing mysteriously when you hit a discontinuity point
   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 interact
   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
   Alex: So I think we should include the margin in the parent's height
   Steve: I realize the agreements reached in Oslo are very fragile, would
          doing what Alex says break those agreements?
   David: No
   Anne: So it seems all browsers are doing different things
   Alex: we could do Opera's solution (collapse the bottom borders even in
         the presence of min-height)
   fantasai: That would not make sense if the min-height is big enough to
             contain the margin
   Alex: but its behavior is continuous
   Discussion about what is intuitive
   Steve: It really bothers me that we don't have any designers here
   Steve: At least Alex's proposal is consistent with what happens when
          margin collapsing is turned off elsewhere
   David: I think from a designer's pov parent-child margin collapsing was
          a mistake
   Peter: There are cases where it makes sense from a designer's pov
   Peter: what doesn't make sense is the margin collapsing turning on and
          off for inexplicable reasons
   Peter: The margin of a box should not begin somewhere far below the box,
          it should always be attached
   fantasai: You're asking for partial collapsing
   David: That's what we decided never to do in Oslo
   Alex: Let's suppose the next element has a top margin of 300px, what will
         that margin collapse with?
   Steve: It shouldn't make any difference, it will collapse with the
          collapsed result of what we get here
   Steve tries to explain the margin collapsing model
   Bert: What about when we introduce vertical-alignment?
   fantasai: We decided that that would create a new block formatting context,
             then you wouldn't collapse the parent and child margins
   Alex: ... partial collapsing
   Bert: That was the original intention, that you take the lowest of the
         bottom of the relevant margins
   Anne: Is it really worth making margin collapsing that much more complicated?
   discussion of usage of margins
   Margin collapsing is designed not for layout, but for when you have a
     continuous flow of content: headings, paragraphs, etc
   fantasai: We have several options here, let's list them
   A. Firefox's behavior, which to truncate to min-height and ignore the
      child margin
   B. Alex' 1st proposal, which is to growt include the child and min-height
   C. Opera behavior: collapse margins, then apply min-height
   D. Define partial collapsing
   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
   David: But that's really a huge change at this point
   Steve: Are there other cases where this happens?
   David, Bert: There are other cases with clear where something like this
   David: The concept of clearance was created in the discussion I'm talking
   David: Before 2003 clearance didn't exist, clear just added a margin which
          then collapsed
   <dbaron> It's not really partial collapsing -- it's making the top/bottom
            edge of an element be in the middle of its margin
   <dbaron> but that's what we decided to avoid in 2003.
   Alex: but floats...
   David: We ended up saying that the position of a float can be in one of
          these places
   <dbaron> To be clear, I really don't want to change the big stuff (i.e.,
            go with (D)) at this point.
   fantasai: Do we have consensus on eliminating D?
   Steve: No, because that's what would make the most sense from a designer's
   Alex: Min-height is as currently specified has a side-effect on margin
         collapsing that is not intuitive to the designer
   Steve: I'm trying to think of reasons why a designer would set min-height
   Alex: Let's try to come up with examples
   Alex: maybe I have business cards, and I set min-width min-height to 2/3
   Alex: so if someone's card has more info at least it shows
   Steve: in that case I wouldn't want the child margins to spill outside the
   Alex: Say I have a series of paragraphs and a div around some of them
   Alex: Don't want setting min-height to make the margins between the
         to disappear
   <dbaron> E. Say min-height != 0 always prevents collapsing.
   Daniel: I use min-height all the time.
   Daniel: I have a <pre>, and I want a minimum height for my code box
   <dbaron> Designers aren't really using min-height in the wild because of
            IE support, I think.
   everybody has a different idea of what designers would want for min-height
     and margin collapsing
   fantasai posts to twitter and gives up trying to minute
   Discuss dbaron's option E
   Alex: That's what IE8 impelements, and I'm not convinced it's more intuitive
   Alex: Min-height normally doesn't have any effect when the min-height is
         very small
   David: Using min-height along with an auto height has two uses
   David: You're saying to use the maximum of the content height and the given
   David: We don't know which is going to be the normal case, it's different
          for different uses
   <anne> (in the case where you really want to use the margin of the parent
           you just use parent > :last-child { margin-bottom:0 } )
   David: in some cases your base case using the content height, and the
          min-height is an exception
   David: 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)
   fantasai thinks that david baron's point here is really important!!!
   <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"
   Steve: We remove the line that says min-height turns margin collapsing off.
   Steve: Then we still have the question of how margin collapsing behaves when
          it's on and min-height has an effect
   RESOLVED: min-height does not turn off margin collapsing
   fantasai is skeptical and reserves judgement


ScribeNick: SteveZ

CSS2.1 issue 60 - Z index

   fantasai: Issue #60 is that Appendix E conflicts with chapter 9 in the
             CSS2.1 text
   <fantasai> http://dev.moonhenge.net/css21/spec/z-index/
   Start with 2.1. Stacking context–like behaviour
   This topic is postponed until tomorrow so that Hixie can participate

Value pseudo attribute

   David: this camee out of discussion on WhatWG list
   David: there was a proposal to have text (specially identified) that can be
       typed over
   David: Styling should specify how that text is specially identified
   David: this is attribute like, but not actually an attribute
   Anne: This is sort of like a DOM attribute
   Anne: it seems to apply to placeholders
   David: you could combine it with the focus selector
   <fantasai> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016544.html
   <anne> WebKit has implemented :-webkit-placeholder for this case. That
          works for focusing the input control as well and such.
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2008Oct/0144.html
   <dbaron> but it would actually need input[:value=""]:not(:focus)
   Daniel: I was wrong to complain that it would be difficult to internationalize
       because this applies only to the content of an attribute
   Anne: When this facility (sample text) is added to HTML, then having a
        placeholder pseudo element would make sense
   Bert: 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
   Bert: the above point is really an HTML not a CSS point
   * Bert (About previous topic: If there is really no room to put the label
           next to the text box, then a compromise might be to put it inside,
           but in gray rather than black text. Safari's search box does that.
           Gray text looks less "selectable" than black text.)


   Does the current Hover element apply to the parent if the child is outside
     of the display space of the parent
   <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/65
   <anne> test
   Daniel: e.g. a child element is relatively positioned outside its structural
   <anne> (that test tests the behavior)
   <anne> (being discussed)
   Daniel: all browsers do selection of the parent
   Alex: 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
   Anne: There are other examples which depend on this behavior
   Daniel: 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.
   Daniel, fantasai: this probably needs a note in the spec
   David: you figure out which element would receive the event and that element
          and all its ancestors are in the hover state
   David: you have to keep compatibility with hovering over a link or any of
          its descendents will keep the link in the hover state
   Peter: 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
   David: the behavior of events on hidden elements is not consistent across
   David: SVG has a property called "pointer events" that may make sense to
          adopt at some point
   David: right now this is massively undefined in the selector spec; I would
          favor more specification as would Peter
   Anne: Say when the element is in "the hover state" (as defined by some
         spec) then the behavior is ....
   David, fantaai: but is there a spec that defines "the hover state"
   David: We can define things in terms of DOM level 2 events (a REC)
   David: we are leaving the hit testing definition to some other spec, but
          we can define the rest now
   David: why are we changing only hover and not "active"
   fantasai: "active" is not well defined
   fantasai: in IE an element remains active even after a click is released
   Alex:: this works on the iPhone
   Peter: thie activity persists during a load, but not forever.
   David: does it matter that browsers have different behaviors for "active"
   fantasai: the differences are so subtle that it is OK
   David: 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
   fantasai: I would say that "active" does not propogate up; e.g. clicking on
             something (a span) inside an anchor makes only the span active
   <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>
   Anne: active only applies to the element being activated is active,
         but in Mozilla and Webkit the ancestors are active as well
   Anne: I thnk that in Firefox, nested links have some anomolies in behavior
   fantasai: CSS does not define what elements get activated or for how long
   <fantasai> or what triggers the activation
   David: current spec says "while it is being activated" not "while it is
   David: not sure that this is something that should be defined differently
          in different specs
   fantasai: e.g. clicking on something (a span) inside an anchor makes only
             the *anchor* active (not the span)
   fantasai: and clicking on a triple-nested link should only apply :active
             to the link that's been activated
   Doug Schepers: there are two specs that define states: SMIL and an MMI spec
   <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")
ScribeNick: dbaron
   fantasai: So I want text for the :hover issue.
   fantasai: I'm ok with saying that the parent of an element that's :active
             is not necessarily :active, but that :hover is propagated to
   <anne> data:text/xml testcase as link http://annevankesteren.nl/test/css/temp/003.xml
   Bert: Leave it undefined for :active because we don't know what elements
         can be activated.
   <anne> So I said that Opera activates the innermost link, where Firefox
          activates the outermost
   David: ?
   Daniel: The original issue was just this one clarification.
   David: But it was a clarification about something that's explicitly undefined.
ScribeNick: SteveZ
   <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)
   Bert: if an ancestor has a hover selector does that block propogation?
   Peter: no, the existance of selectors is independent of event propogation
   Bert: if you have two ancestors with pop-ups on hover, you will get both
         unless the first one blocks propogation
   <fantasai> proposal:
   <fantasai> If an element that is ':hover' causes its parent to be ':hover',
   <fantasai> then it is possible for an element that is not underneath
   <fantasai> the pointing device to be ':hover'.
   <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
   <fantasai> If it's possible for ':hover' to apply to an element because its
   <fantasai> child is designated by a pointing device, then it's possible for
   <fantasai> ':hover' to apply to an element that is not underneat the pointing
   <fantasai> device.
   Bert: 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
   <fantasai> If it's possible for ':hover' to apply to an element because its
   <fantasai> child is designated by a pointing device, then it's possible for
   <fantasai> ':hover' to apply to an element that is not underneath the
              pointing device.
   David: the WG did not resolve that hover was heirarchical but with IE8 all
          implementations seem to make it hierarchical
   <SteveZ> N.B. the above text by fantasai is intended as a NOTE
   <fantasai> checked in
   <fantasai> RESOLVED: proposal above accepted
   <dbaron> http://dbaron.org/css/test/sec051103b is a testcase for hierarchical
            :hover (and :active)
   Daniel: although whether hover applies to ancestors is officially undefined;
           millions of websites would break if it were otherwise defined
   <shepazu> I'd just like to note that you could define "hovered" as being defined by the host language
   <shepazu> then it's not CSS's problem
   <dbaron> http://dbaron.org/css/test/sec051103b is a testcase for
            hierarchical :hover

Grammer for an+b for nth child

   <glazou> http://www.w3.org/Style/CSS/Tracker/issues/66
   fantasai: 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"
   David: the odd and even need to be case insensitive
   <dbaron> You want the n, the even, and the odd to be written using the
            {n}, {o}, etc. productions from the grammar
   <dbaron> and it would be nice to indent so the [] and () don't line up
            with the | because they look a lot like |
   Daniel: the 'n' is escapable, but not the "+" or "-"
   <dbaron> (since units are escapable, but sign is not... right?)
   RESOLVED: the proposed grammer is accepted, with the modification to
             allow the 'n' is escapable.


   <dbaron> Ah, so we haven't had the pseudo-element argument for a few
            years, so we need to do it again...
   <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/67
ScribeNick: fantasai
   David: Pseudo-elements have this thing where their boundaries don't
          line up with the tree
   David: The question is do you split the <span> into 2 pieces, or do
          you split the pseudo-element into 2 pieces?
   David: The current spec says you split the pseudo-element
   Daniel: Can the pseudo-element contain more than pcdata and replaced
   Peter: you could have a selection, for example in the example in 67
   Peter: you can't contain the children and still be well-formed
   <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>?
   Peter: the HTML5 spec might say something about this, wrt malformed
   Peter: In this scenario, what you get with the pseudo-element should
          always be describable as valid tree markup
   Daniel: It's describable as a DOM range
   David: The problem is that many CSS properties, including inheritance,
          are defined in terms of a tree
   Daniel: Question remains, do I have multiple outlines for
   David: What Mozilla actually implements now, I think, is something
          that sounds even more complicated than these two
   David: We do both
   David: We do one for the inherited properties and one for the
          non-inherited properties
ScribeNick: SteveZ
   David: Mozilla implements that 3rd option: it treats the inherited
          and non-inherited properties differently
   Daniel: I wonder if we should just remove outline from the list of
           properties allowed?
   David: I'm not even sure if that's quite what we do
   <anne> http://annevankesteren.nl/test/css/temp/004.xml
   Anne: Opera doesn't apply outline at all
   Bert: 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
   Anne: It seems nobody implements outline
   Peter: What about p::selection { color: inherit } ?
   -!- mollydotcom has joined #css
   David: Warning: at some point I may want to propose styling of multiple
   David: "background" is non-inherited so its behavior would be the same
           as that for "outline"
   <dbaron> I think for ::selection it's important that the ::selection
            is innermost for the 'color'.
   Anne: if there is a span::selecction it should apply; it does in Opera
         but not in Firefox
   <dbaron> With ::selection, do you ever get
            or something else?
   <glazou> hey mollydotcom!!!!
   <mollydotcom> greetings all
   <dbaron> and how do global ::selection styles interact with that?
   <mollydotcom> catching up on the topic, having tea to wake up, be
                 with you all in a bit
   David: Suppose you have a selection that includes an element that
          is 20 levels nested
   <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?
   <dbaron> Do you have 20 pseudos?
   David: If you have p::selection and you set a color on it and you have
          a span inside the p, you want the selection inside the span to
          have the color you set on p::selection
   David: So this is not a tree-based approach. How do you deal with
   p::selection { color: blue } span { color: purple; }
   <dbaron> <p>Text << text <span>span</span> text >> text.</p>
   <dbaron> we want the "span" to be blue rather than purple
   <dbaron> We definitely don't want to distinguish "in the selection"
            from "contains the selection" because it can be half and half.
   <dbaron> What about 'color: inherit' ?
ScribeNick: 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
   Steve: A selection is a set of DOM ranges.
   Steve: That's the One Selection
   Steve: Then there's the issue of how to style it
   Steve: The proposal is to style it as if the selection is not there
   Steve: Then go back and for the pieces that fall into the range, you
          restyle them
   Anne: That's not desired for the span case because then p::selection
         would not apply to the span nested inside the p
   David: I think it would help to have concrete examples
ScribeNick: SteveZ
   Daniel: I will come up with a list of requirements for what ::selection
           should and should not do
   Daniel: one requirement is that we do not want nested outlines
   Daniel: we want color to nest locally
   <Bert> How about: insert <::selection> at the start, </::selection>
          before every tag, <::selection> after every tag, and </::selection>
          at the end: <p>...........<<<<::>.......</::></p><::> </::>
   <Bert> (and then think about 'outline' separately)
   ACTION: glazou, develop requirements for ::selection behavior
   <mollydotcom> I look at this and try to imagine designers having a clue.
                 It isn't working.
   <mollydotcom> just bear in mind designers want very explicit control of
                 every piece within a given selection

   ACTION: fantasai or dbaron write double-cascade proposal for ::selection

ScribeNick: fantasai
   <glazou> http://lists.w3.org/Archives/Public/www-style/2006Jan/0209.html
   <glazou> http://lists.w3.org/Archives/Public/www-style/2006Jan/0091.html
   David: I think this is what we solved by doing the inherited/non-inherited
          properties split
   David: He put a display property on the :first-line and then
          display:inherit on a span in the first line
   <glazou> http://lists.w3.org/Archives/Public/www-style/2005Oct/0163.html
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2005Oct/0163.html
   David: What we used to do on this test case was crash
   David looks up what exactly Mozilla does here
   David: If you have property: inherit; on an element that is inside the
          :first-line, then we don't inherit from the :first-line
   David: for non-inherited properties
   David: The effective change for this is only when the 'inherit' keyword
          is used on a non-inherited property
   David: That's a very uncommon case
   David: It's possible we want to change the behavior on more common cases
   David: like a tiled background image on ::first-line
   David reviews the spec
   David: no, that's should probably work...
   David: So how should we be changing the spec to try to address this?
   David: The current spec says that the span is split into two separate boxes
   Daniel: How should the spec be changed to allow/require what Mozilla does?
   David: Do we want to say what Mozilla does with inheritance is allowed,
          or required, or it's undefined, or make another change
   Alex: IE does exactly what Mozilla does at this point.
   Alex: inheritance comes not from the pseudo-class but from the actual parent
   David: but for an inherited property like color?
   Alex: doesn't inherit
   David inspects Alex's testcase
   <Bert> (Is it the case that properties that don't apply to :first-line
          are also not inherited from :first-line? Or are only non-inherited
          properties not inherited?)
   <fantasai> dbaron clarifies that in Mozilla only non-inherited properties
              are not inherited from :first-line
ScribeNick: SteveZ
   David: explicit inheritance of non-inherted properties ignores the
          firstline and firstchar properties in computed the inherited value
   David: inheritence of inherited properties do use the properties of
          firstline where relevant
   fantasai: the split between non-inheritable properties do not inherit
             from the pseudo element properties and inheritable properties
             do inhert makes sense
   Alex: background and text decoration are safe to inherit
   Bert and David: position and float are not safe to inherit
   David: if you set "whitespace: nowrap" this may change the firstline
          behavior (beyond just the inheritance question).
   Bert: The keyworld inherits from either the parent of the first line or
         the firstline; which should be used?
   Bert: one rule might be to inherit from the firstline if the property
         is applicable to the firstline and the parent otherwise.
   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
   <fantasai> s/parent/non-pseuo-element parent/
   add: The portion of a child element that does not occur on the first
     line always inherits from the parent of that child.
   RESOLVED: proposal above accepted
   David: Firefox does not have the same rules for firstletter because
          firstletter is not layout based; it is only storage order based
   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

<glazou> ======== ADJOURN FOR TODAY ===========
* fantasai wants ideas for http://lists.w3.org/Archives/Public/www-style/2008Sep/0142.html yo
Received on Wednesday, 5 November 2008 03:49:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:16 GMT