W3C home > Mailing lists > Public > www-style@w3.org > August 2012

[CSSWG] Minutes and Resolutions San Deigo F2F Mon 2012-08-13 AM: @supports and Selectors 4

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 27 Aug 2012 15:57:21 -0700
Message-ID: <503BFB51.4010802@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
CSS Conditional Rules Level 3

Discussed OM for @supports:

   - RESOLVED: Have intermediary condition rule interface called CSSConditionRule
   - RESOLVED: .conditionText on the common interface;
               for @media it is equivalent to .media.mediaText
   - RESOLVED: .conditionText returns either the token stream or source text
               from the style rule, with no logical simplifications, just
               tokenization ones
   - RESOLVED: CSS.supports() with one (conditionText-compatible) or
               two (property, value)  arguments. Fall back to
               window.supportsCSS if not possible.
   - RESOLVED: property name must be the name, no escapes, no spaces,
               it's not parsed it's just a name. value can be anything
               taken as a value

Selectors Level 4

   - Section added to define selector scoping:
     Better terminology suggestions welcome.
   - Discussed drag-and-drop selectors, see resulting summary at
   - RESOLVED: Add :user-error pseudo to represent :-moz-ui-invalid
     Issue raised about :user-interacted
   - RESOLVED: Publish next draft with subject indicator as a ! before
               the subject; issue open on whether before or after.
   - RESOLVED: Publish Selectors Level 4 as WD

====== Full minutes below ======

<RRSAgent> logging to http://www.w3.org/2012/08/13-css-irc
Agenda: http://wiki.csswg.org/planning/sandiego-2012

   Glenn Adams
   Rossen Atanassov
   Tab Atkins
   David Baron
   Bert Bos
   Tantek Çelik
   John Daggett
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   Vincent Hardy
   Koji Ishii
   Peter Linss
   Florian Rivoal
   Ted O'Connor
   Alan Stearns
   Leif Arne Storset
   Steve Zilles

CSS3 Conditional Rules / @supports
Scribe: fantasai

   <dbaron> http://dev.w3.org/csswg/css3-conditional/
   dbaron: We've published one WD to /TR
   dbaron: There's been some minor tweaks
   dbaron: and the addition of a bunch of OM stuff to spec
   dbaron: Want to discuss mainly OM stuff today

   dbaron: One piece is relatively straightforward: 8.1 is numbers.
           We used 12 and 13

   dbaron: 8.2 is relatively straightforward
   dbaron: in that we already have an interface for MediaRule that has
           all but the first attribute here
   dbaron: instead of conditionText it has mediaText
   dbaron: 1. Is conditionText right?
   dbaron: 2. Do we want a parent interface on which the bottom three
              are shared?

   glazou: We ask browser if it supports a property and a value
   Tab: No, it's more than that -- it's conjunctions with and/or/not,
        not just a single property declarations
   Tab: You could make a tree structure for it, but I don't know how
        valuable that is
   dbaron: Doubles implementation work of @supports
   Florian: Let's not do that until someone asks for it

   dbaron: I named it conditionText to match a bunch of other things that
           end in Text in the OM
   fantasai: Question, it's mediaText for MediaRule, why is it
             conditionText for SupportsRule?
   Tab: you're thinking it should be supportsText?
   Tantek: Seems confusing, asking if it "supports Text"
   fantasai: But all these things are condition rules, why is only this
             one called conditionText?
   Florian: Would be nice if all three rules used conditionText
   dbaron: I think mediaText is in the other chapter of DOM 2 Style...
   Florian: So .media.mediaText could be equivalent to .conditionText
   Florian: And have all of them have .conditionText
   Daniel: So for @media, .media.mediaText and .conditionText would be
   dbaron: yes
   glazou: for both getting and setting?
   dbaron: yes

   glazou: Wrt additional common interface, would that get implemented?
   dbaron: My inclination would be to put it in the spec and mark it at risk

   Florian: Back on conditionText itself, need to define how serialization
   Florian: In your stylesheet, if you have not not not, do you collapse
            into one not?
   Tab: Are you allowed to do logical simplifications
   Florian: I'd like to simplify
   Tab: I'm ok with that
   Florian: also multiple nested parens that don't do anything, can you
            collapse that
   dbaron: Don't want to require that ...
   Florian: Want to have identical serializations across browsers
   dbaron: We wanted to use a token string
   Florian: We copy the string exactly from the style sheet
   Florian: ... we simplify
   dbaron: I don't think there's a need to simplify
   dbaron: It's extra code on our end to simplify
   Florian: In my case what I wrote was the easiest implementation
   Glenn: Need to define this if you want to test it
   fantasai: Authors will want to predict what they get back, and get
             consistent results, if they want to tweak it and write it back
   Florian talks about preserving invalid conditions
   Glenn: What about white space and comments?
   fantasai points to the current spec, which has a proposal
   dbaron: I think in order to preserve semantics, you need to preserve
           where comments are, if not what's in them
   Florian: Seems easier to just pass through the string
   glazou: So you empty the comments, and report back an empty comment?
   Florian: No, if we do this, we'd preserve the comment
   dbaron: Sounds like we both implemented at a layer above the tokenizer,
           went back to stylesheet and pulled out the text
   glazou: Still match curly braces etc?
   dbaron: As we parsed, yes. We mark the start and end in the style sheet
           data, and pull that directly back out
   glazou writes on the board:
     @supports (foo: {;};);
   dbaron: That's syntactically because of the second semicolon... and
           the third semicolon
   glazou errases that and writes
     @supports (foo: {;} blah)
   glazou: Catch everything correctly?
   dbaron: yeah
   Florian writes
     @supports (foo: {;} blah) and (bar:baz)
   Florian: We preserve the contents of the parens, but we parse and
            normalize the structure around it
   Florian adds more parens and double nots, points out that they get
           simplified out
   dbaron: We don't preserve any structure

   Florian discusses the possible addition of .condition, which would have
           a tree structure, and asks whether that should be simplified
   plinss thinks it's better not to simplify
   plinss: Reason not to simplify is that I'll want to mainpulate via
           script, plug things into levels, don't want those levels to
           disappear on me

   glazou: I think I prefer dbaron's approach
   glazou: Being able to read back the condition exactly as the author
           wrote it is good
   Glenn: what about the case when you construct via script?
   dbaron: It's the same
   dbaron: I want to allow outputting a token stream rather than the text
           from the style sheet, so the implementation could replace \S+
           with a space
   dbaron: And would be allowed to drop contents of a comment, could do so
   dbaron: They can't drop the comment
   glazou: I would prefer if you don't do that
   Tab: Would prefer to do that, because otherwise you have to go back to
        the source text
   Tab: Once you have a parse tree, theoretically you should be able to
        kill the source text
   Tab: The exact source text doesn't exist in the parse tree, because
        the parse tree is made of tokens
   Tab: Implementations that don't preserve the source text should be able
        to implement this
   dbaron: While what I'm proposing isn't 100% precisely defined, it's
           better than almost everything else in the CSSOM

   Discussion of grouping rules (contain declarations) vs. others?
   Tab: Need to look at @keyframes
   plinss: @page
   Name of common interface?
   glazou: If it's conditionText, should be ConditionRule
   glazou: to be consistent
   Tab suggests we have GroupRule and ConditionRule.

   RESOLVED: Have intermediary condition rule interface called CSSConditionRule
   RESOLVED: .conditionText on the common interface;
             for @media it is equivalent to .media.mediaText
   RESOLVED: .conditionText returns either the token stream or source text
             from the style rule, with no logical simplifications, just
             tokenization ones
   <dbaron> (i.e., could optionally collapse whitespace or drop contents
            of comments)

   jdaggett: What should we be doing for new @rules, are we defining a
             specific serialization?
   Florian: This one is pretty specific
   glazou: I suggest we take that question to the OM discussion
   glazou: DocumentRule?

   Florian: have to decide normalization of conditionRule for URLs
   dbaron: normalization of urls is hard, might require us to drop
           @document from the spec atm

   dbaron: 9.3 is OM interface to do @supports queries
   dbaron: I feel strongly that this should not allow logical combinations,
           because JS can do that
   glazou: We had the exact discussion with matchMedia, and came to the
           exact opposite conclusion
   glazou: supportsCSS is good as it is, maybe we need another interface too
   Tab: We did the entire media query for matchMedia so that you could
        attach a listener
   glazou: I agree, but from an author's perspective
   sylvaing: People will want to pull from conditionText and put it into
             the matching function.
   Tab: you can't interchange media queries and support queries
   Tab: There are some that look identical

   fantasai: So, the comment I have here is that supportsCSS seems very
             general, but this only takes a property-value pair
   Tab wants the name to be short
   * sylvaing in Java this would be AbstractSupportCSSPropertyValuePairHelperImpl
   sylvaing: Is there any objection to the functionality here?
   glenn: Do you want to query a property with any value?
   Tab: We are specifically *not* doing that.

   glenn: I'm ok with the functionality, concerned about where it is attached
          (window object)
   glenn: Could attach to navigator
   Tab: I propose creating a new CSS object and attaching it to that
   Tab: Right now the constructors for everything else have enormous names,
        e.g. CSSPixelValue
   Tab: would be nice to be able to say CSS.px()
   Florian: 3 acceptable proposals to me: window, navigator, or what Tab
            is saying
   fantasai agrees with Florian
   Glenn: Keep in mind that properties on window are shadowable
   dbaron: That was true in ECMA262 Edition 5, which was regression from
           Edition 3, and was fixed in 5.1
   fantasai: Would expect CSS.supports() to be the function that takes the
             whole @supports condition string
   dbaron: want to avoid supportsProperty because ECMA uses properties
   dbaron: Could be ok with supportsCSSValue
   Florian: CSS.supportsValue
   Florian: Still reasonably short
   <stearns> +1 to supportsValue

   some meta-discussion
   Florian points out it is being implemented now
   jdaggett is not buying this argument, we get a lot of this situation of
            implementing things in editor's drafts
   fantasai proposes compiling list of proposals, posting to www-style,
            discussing over breaks, and revisiting later

   Bert: Does window always exist?
   Tab: A global object exists, and for compat reasons it's called window
   0. window.supportsCSS()
   1. CSS.supportsValue()
   2. CSS.supports()
   <hober> CSS.supportsPropertyValue()
   <fantasai> no!
   ACTION glazou: email www-style
   <trackbot> Created ACTION-489

   Florian: Issue -- you strip WS at the ends, do you also strip comments?
   dbaron: You trim the property name, because it has to be a property name
   Florian: So, around value, whatever, around property, nothing. Ok
   dbaron: Expects property to be a property, and value to be anything
           that's allowed in the value, including white space and comments
   Bert: Is the property normalized?
   fantasai: What about escapes
   dbaron: You're not parsing CSS, just taking a property name
   Bert: Unicode normalization?
   Tab: Not an issue, our properties are all ASCII
   sylvaing: What if you pass in a variable name?
   RESOLVED: property name must be the name, no escapes, no spaces,
             it's not parsed it's just a name. value can be anything
             taken as a value

   glazou asks about tests
   Opera has submitted theirs, Mozilla needs to submit theirs
   expect order of 100 tests
   <stearns> my word-count/test ratio heuristic says that css3-conditional
             will need 334 tests


   Tab: So, fantasai Florian and I have a suggestion
   Tab: We like CSS.supports(), but it implies very generic, so have that
        take the conditionText of a supports rule
   Tab: Don't like how matchMedia requires parens around a single thing,
        so I like 2-argument form for readability for simple tests
   fantasai: For two-value, was it CSS.supportsValue()?
   Florian: No, CSS.supports() with two arguments it works as currently defined
   Tab: So I'm suggesting CSS.supports() 1-argument form taking an @supports
        condition and a 2-argument form taking property and value
   dbaron: I'm worried that creating this CSS object might be more controversial
   dbaron: But I'm ok with giving it a try
   hober: Concerned about compat with random websites that use CSS as a global
   Tab: If CSS doesn't work, ok with reverting to window.supportCSS
   Glenn prefers CSSStyleRule.supports
   Tab: We wouldn't look at that until testing support for @rules anyway
   szilles: It isn't CSS supports, its UA supports
   RESOLVED: CSS.supports() with one (conditionText-compatible) or
             two (property, value)  arguments. Fall back to
             window.supportsCSS if not possible.
   ACTION TabAtkins: ask WebApps about global CSS object
   dbaron: Don't have an extra feedback request to www-style right now
           (reduce bikeshedding); we'll get feedback on the minutes and
           on the draft.

Selectors Level 4
Scribe: dbaron

   <fantasai> http://dev.w3.org/csswg/selectors4/
   fantasai: some changes since we last discussed this

   fantasai: scoped selectors (3.3):  we defined 2 ways of scoping selectors
   fantasai: these are the 2 ways available in HTML and the OM.
             We gave them names so those specs can refer here.
   fantasai: Also updated prose for :scope pseudo-class.
   Tab: If someone can come up with better names than contained and
        constrained, that would be appreciated.  Not different enough.
   glazou: querySelector on an element?
   fantasai: yeah, example 2 should refer to Element.querySelector()

   fantasai: Other change to discuss is 8.4: :valid-drop-target
   fantasai: We resolved to add this.
   fantasai: But Sylvain pointed out that we should be limiting it to the
            one that you'd drop it on right now
   glazou: :valid-drop-target:active ?
   fantasai: It's not being activated right now.
   glazou: Like when you click and haven't released the button yet
   fantasai: I think it would be more confusing.
   fantasai: I looked over other suggestions in the minutes, there was a
             lot of agreement on :active-drop-target
   fantasai: We switched from it in order to distinguish between valid
             and invalid drop targets.
   fantasai: But that seems a bit abstract.  I think Sylvain's issue is
             more important.

   fantasai: We could have three pseudo-classes (maybe not now, but in the
             future):  we could have :valid-drop-target and
             :invalid-drop-target that indicate possible drop targets.
   [discussion about invalid vs. not drop target]
   fantasai: proposal is to rename to :active-drop-target, and if we want
             to distinguish :valid and :invalid later we can add them
   glazou: Behavior you describe is not in conformance to mouse clicks
   glazou: I think :valid-drop-target:active is better
   glazou: Need :dropped
   fantasai: Original request is what will receive the drop if I let it go
   fantasai: I don't want to have to combine pseudos for this

   Tantek: other name suggestions from cursor:no-drop
   fantasai: If we went with that, :active-drop, :drop, :no-drop
   * Bert wondering about *:drop-target:hover = dragged over,
                          *:drop-target:active = dropped on
   * sylvaing this is what daniel proposed earlier. drag-and-drop and
              activation are different things
     :active-drop would be the thing about to receive the drop if dropped now,
     :drop is any valid drop target, and
     :no-drop is a drop target that's not valid
   Tab: [speaking at >150wpm]
   Tab: The :invalid pseudo-class doesn't apply to all the dom, only things
        with validity constraints.
   <arronei> how about :drop-target and :no-drop-target
   <fantasai> arronei, I like :active-drop and :drop, they're nice and short
   <fantasai> arronei, the -target part doesn't seem necessary
   <arronei> just saying :drop isn't explicit enough in my opinion
   <arronei> does it mean I can drop something or I am dropping something?

   Bert: difference between :active-drop and :drop:hover ?
   fantasai: might not need to actually be inside the boundary
   fantasai: Solitaire on windows actually has two options for this behavior:
             can drop only if hovering over a valid drop target, or can go
             to the closest one from wherever it's dropped
   Bert: at least cover a part of it?
   fantasai: not in all interfaces
   Florian: [asked Q]
   Florian: difference between :drop:hover and :active:drop -- in theory?
            in practice?
   fantasai: [really fast]
   dbaron: You might not be triggering :hover at all with drag and drop
   fantasai explaining that interfaces might trigger drops even if not hovering
            e.g. solitaire on windows, or non-mouse-driven drag-n-drop
   Tantek: I think this use of :active is a different semantic from :active
   Tantek: bad from teaching perspective. Closer to :hover than :active.
   Florian: :current-drop ?
   Tantek: with some drag&drop interfaces, button might not be down
   Tab: I like :can-drop
   Florian: That's :drop, not :active-drop
   fantasai: :will-drop, :can-drop, :no-drop
   fantasai: :current-drop, :can-drop, :no-drop
   Tantek: :can-drop, :drop, :no-drop
   (these are in order of replacing :active-drop-target, :valid-drop-target,
   fantasai: :drop, :can-drop, :no-drop
   Florian: :current-drop, :valid-drop, :invalid-drop
   Florian: I don't like :no-drop because it sounds like it includes things
            that aren't drop targets.
   Peter: but value in being consistent with cursor
   ?: no-drop cursor could be used where not a drop target
   Tantek: That's not how it's used in UIs.
   glazou: I'm not seeing this discussion going anywhere.
   fantasai: [pointing at the board] I like these 2, these 2 ok, really
             don't like these 2.
   now down to:
     :active-drop, :drop, :no-drop
     :drop, :can-drop, :no-drop
     :current-drop, :valid-drop, :invalid-drop
   Steve: I don't like :drop
   ACTION fantasai to email www-style about the possiblities
   <trackbot> Created ACTION-490
   Florian: I suggest putting all 3 in the spec, and put the later two at risk

   fantasai: Next thing for discussion is :user-error (11.5)
   fantasai: We had proposal for :-moz-ui-invalid, :invalid limited to when
             user has already interacted with it.
   fantasai: Mozilla has some heuristics for when :-moz-ui-invalid is triggered
   fantasai: But the idea is to match it when you actually want to
             highlight things as invalid.
   fantasai: Tab and I came up with the name :user-error. Matches a control
             that is required but not yet filled in, or that has invalid input
   glazou: In case of elements implemented by UA, I understand.  What about
           elements implemented by the Web author?
   Tab: setCustomValidity can do that
   dbaron: The problem we're dealing with here is that some elements are
           invalid when they haven't yet received input.
   dbaron: If someone is doing a custom control, they need to call
           setCustomValidity in that state where they haven't yet received
   dbaron: ...so that the form can't be submitted in that state.
   dbaron: But you still need to know when the control has received input.
   dbaron: need an API for that
   Tab: Not sure that's necessary here because if it's a custom control,
        you can put a class on it
   fantasai: [reads definition of :user-error]
   dbaron: [explains rationale for :-moz-ui-invalid]
   fantasai: In terms of custom controls, you want it to really be :invalid
             whenever it's invalid.

   Tantek: More background here: one of the reasons for :-moz-ui-invalid
           was a short-term fix to be able to build UI because :invalid
           wasn't reasonable for UI.
   Tantek: But there was discussion of not trying to combine meanings in
           one pseudo-class -- there was discussion of having a pseudo-class
           for whether the user has interacted with the element at all.
   Tantek: If we're actually trying to fix this properly, we might want to
           consider this orthogonal pseudo-class.
   Tantek: That was the context of the discussions about how :-moz-ui-invalid
           came to be.
   fantasai: I'm happy to spec whatever you want to implement.
   Bert: Sounds like :fresh
   Tantek: or the opposite
   Tantek: :user-dirtied
   fantasai: :user-interacted
   Tantek: A little vaguely defined -- tabbing through, clicking and then
           clicking elsewhere
   Tantek: Don't want prematurely precise specification.
   Tantek: ... distinguish between user-interacted with form or interacted
           with element?
   Peter: We can't know what all possible ways of interaction will be over
          next 10 years.
   Tantek: specify a simpler thing that designers can combine to get effects
   fantasai: I think we should spec :user-error
   fantasai: e.g., because we need things to be highlighted after user
             tries and fails to submit form, even if hasn't interacted
             with that particular control
   fantasai: I think we should spec this, and add that later when more
             concretely proposed
   Tantek: This is just as concrete -- just the same thing without the
           intersection with :invalid
   Florian: How do you select thing when user pressed submit, failed, and
            the user never interacted with control?
   [lots of fast talking]
   fantasai: wrt distinguishing invalid vs. required-but-missing
   fantasai: could split out :user-omitted and :user-invalid
   Florian: I'd like to have :user-error and also have what Tantek suggested
   Florian: ...
   Tab: That's placeholder
   Tantek and Tab argue about how form UIs are designed
   fantasai: Any objections to adding :user-error as is?
   Bert: Can we add something like what Tantek said?
   Tantek: I'd like to also mention :user-interacted
   fantasai: I think it's separate
   Tantek: Potentially makes :user-error unnecessary.
   RESOLVED: Have :user-error as-is, and have an issue about :user-interacted.

   Tab: Next up is the minor change to the reference combinator.
   Tab: We changed the wording to allow host languages to...
   Tab: Before, attribute had to be IDREF or ID selector.
   Tab: Now, have use cases from Web Components that want more ways to match.
   Tab: Host language can define alternate ways (e.g., full selectors).
   glazou: reference combinator badly needed for epub

   fantasai: Then the column combinator (14.1)
   fantasai: this is a combinator, not a pseudo-class (as it was in previous
   fantasai: needs knowledge of the host language
   fantasai: anything with a tabular structure and a row-major table
   fantasai: In a column-major model, it's a row combinator.
   glazou: The // are really too similar to a reference combinator.
   glazou: why not || ?
   Tab: Intended to look like a reference combinator
   glazou: I don't want 2 things, one with keyword inside and the other
           without keyword inside.
   fantasai: I'm happy with either option.
   glazou: I'm happy with anything, but these really look too similar.

   dbaron: I think I'm not happy with the change from pseudo class to
           combinator, but I don't remember why
   fantasai: pseudo-class would create branching structure
   fantasai: Combinator intended to express relationship between elements,
             not pseudo-class, so makes sense to be a combinator.

   <Bert> q+ to ask if that would also work for 'dt#d1 // dd' for "any of
         the DDs that belong to the DT with ID=d1"?

   glazou: Impossibility to use :nth-child() and friends to style rows
           and columns with spans.
   dbaron: There's another selector here for that.

   dbaron: concerned wrt perf for combinator rather than pseudo-class
   13:52  * Zakim sees Bert on the speaker queue
   dbaron: authors will tend to write the faster option with the pseudo-class,
           but the slower with the combinator
   dbaron: Now that UAs have implemented filtering for descendant combinators
   dbaron: maybe that's not a huge problem...
   dbaron: Another perf problem I forget

   glazou: Alan and I wrote a document for pseudo-elements.
   glazou: at some point want to eliminate restriction on other selectors
           to the right of pseudo-element
   glazou: and then we could have the column as a pseudo-element and have
           selectors inside the table
   dbaron: I actually have a model for selectors to the right of a pseudo-element
           specified in the overflow draft right now, based on discussions
           from one of our meetings
   ACTION fantasai: summarize all issues raised here into the draft
   <trackbot> Created ACTION-491

   Sylvain: This is dependent on document-language constructs?
   fantasai: yes
   fantasai: So wouldn't apply to grids; applies to table elements,
             not display:table.

   fantasai: So, determining the subject of a selector
   fantasai: Discussion on the list about syntax.
   fantasai: Currently using an ! after the subject of the selector.
   fantasai: Seemed better to append it because it splits the selector
             better when appended, avoids connotation with "not" operator.
   fantasai: We need to put something on the compound selector, and it
             either needs to be before or after.
   glazou: Implemented this in STTS 14 years ago.
   glazou: Want ! at beginning because it's visible; hard to see at end.
   fantasai: ! at beginning also looks like "not"
   glazou: Everybody confused by !important, but everybody using it without
           a problem.
   fantasai: We need something either before or after subject.
   fantasai: How does this work with pseudo-elements?

   glazou: Alan and I extracted pseudo-elements spec from selectors4.
   glazou: I think we have two things related to pseudo-elements: syntax,
           and then various pseudo-elements and the behavior they express.
   glazou: I think extraction of pseudo-elements makes sense.
   glazou: Pseudo-elements spec has informative, brief description of syntax.

   fantasai: I would like people to think about this and I'll try to make
             the edits to :user-error.  My goal is to publish a WD on Thursday.
   Sylvain: Did we talk about :lang() updates
   fantasai: I was going to in Hamburg, but forgot
   fantasai: :lang() now accepts comma-separated list, and wildcard matching
             for BCP47
   Florian: This was valuable for Metro?
   Sylvain: Yes, can make style sheets a lot shorter.
   fantasai: Are people ok with this?
   <sylvaing> in scenarios where the content supports many languages -
              web apps/widgets, ebooks - this significantly shortens selectors

   fantasai: Edits tonight, and maybe we can resolve to publish tomorrow?
   Tantek: Maybe capture ! syntax as an issue and publish that way?
   glazou: I'm not ok with that
   fantasai: I'd like to resolve this issue or drop the feature.
   glazou: I want it specified as prepend, though I'm ok with an issue
           noting that it's an issue.
   Peter: Or we could do both.
   Tab: Do we expect this to be implemented in normal CSS?
   <dbaron> did peter mean "before or after" or "before and after"?
   <fantasai> both
   <plinss> before and after
   Tab: I'd like to move this to a profile for batch processors.
   glazou: Top user feedback since 1998.
   fantasai: Do we want profiles for dynamic and non-dynamic?
   glazou: we already have some profiles
   fantasai: I'll create a profile that excludes it from dynamic
   RESOLVED: ! before the selector (with issue about after)
   Bert: Append with a space between?
   * fantasai had considered prepending two ! to solve the not issue
              and to make it more visible

   Tab: Being able to style a column when you hover it isn't addressed
        by anything.
   Tab: Because the column element isn't in :hover

   glazou: stuff on the right of pseudo-element!
   RESOLVED: publish new WD of selectors4

<br type="lunch">
Received on Monday, 27 August 2012 22:57:52 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:58 GMT