- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 27 Aug 2012 15:57:21 -0700
- 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:
http://www.w3.org/TR/2012/WD-selectors4-20120823/#scoping
Better terminology suggestions welcome.
- Discussed drag-and-drop selectors, see resulting summary at
http://www.w3.org/TR/2012/WD-selectors4-20120823/#drag-pseudos
- RESOLVED: Add :user-error pseudo to represent :-moz-ui-invalid
http://www.w3.org/TR/2012/WD-selectors4-20120823/#user-pseudos
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
Present:
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
equivalent?
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
(agreement)
Florian: Back on conditionText itself, need to define how serialization
works
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
CSSStyleSheet
CSSDeclaration
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
<br/>
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
fantasai:
: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
elsewhere
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,
:invalid-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
input.
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
draft)
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 UTC