- From: fantasai <[email protected]>
- Date: Tue, 04 Nov 2008 19:49:03 -0800
- To: [email protected]
<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 UTC