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

Agenda
------
   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.
   (February)
   ?: 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
           comments/constraints

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
           contribute
   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
   (break)
   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
          followed
   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
           XHTML.
   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
             useful.
   Bert: But what happens if people create new formats that reuse parts of
         HTML?
   Anne: If it's in the HTML namespace, then it will have the same special
         behavior.
   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.
   (discussion)
   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>http://lists.w3.org/Archives/Public/www-style/2007Mar/0035.html
   <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
         bigger?
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
         margin.
   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
                happens.
   David: The concept of clearance was created in the discussion I'm talking
          about
   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
          perspective
   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
          box
   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
         paragraphs
         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
          min-height
   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

LUNCH

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.)

Selectors
---------

   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
           parent
   <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
   <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
           browsers
   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
          active".
   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
             ancestors.
   <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
         ancestors
   <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.

::selection
-----------

   <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
           elements?
   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
          markup
   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
           richtext::selection?
   ...
   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
          ranges
   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
            <p::selection><span::selection>sel</span::selection></p::selection>,
            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
          inheritance?
   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><::> </::>
          <p><::>......</::><span><::>......</::>>>>.......</span></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

::first-line
------------
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