15:31:51 <RRSAgent> RRSAgent has joined #css
15:31:51 <RRSAgent> logging to http://www.w3.org/2013/04/10-css-irc
15:31:55 <glazou> Zakim, this will be Style
15:31:56 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 29 minutes
15:31:59 <glazou> RRSAgent, make logs public
15:45:01 <SimonSapin> radial-gradient() is cra
15:45:03 <SimonSapin> crazy
15:45:08 <SimonSapin> (but coming to WeasyPrint)
15:49:54 <sgalineau> sgalineau has joined #css
15:51:59 <glenn> glenn has joined #css
15:53:21 <glazou> eheh
15:53:33 <glenn_> glenn_ has joined #css
15:55:30 <Zakim> Style_CSS FP()12:00PM has now started
15:55:37 <Zakim> +??P26
15:55:41 <glazou> Zakim, ??P26 is me
15:55:42 <Zakim> +glazou; got it
15:55:49 <glazou> Regrets: leaverou
15:56:11 <Zakim> +sgalineau
15:56:21 <Zakim> +plinss
15:56:21 <glazou> Regrets: +florian, danielweck, SimonPieters
15:57:41 <Zakim> +Stearns
15:58:41 <rhauck> rhauck has joined #css
15:59:31 <Zakim> +rhauck
15:59:45 <Zakim> +glenn
15:59:48 <Zakim> +antonp
16:00:07 <nvdbleek> zakim, code?
16:00:07 <Zakim> the conference code is 78953 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), nvdbleek
16:00:24 <plh> plh has joined #css
16:00:25 <Zakim> +SimonSapin
16:00:27 <oyvind> oyvind has joined #css
16:00:27 <BradK> BradK has joined #CSS
16:00:33 <Zakim> +Plh
16:00:36 <jdovey> jdovey has joined #css
16:00:38 <dael> dael has joined #css
16:00:46 <Zakim> +Tab_Atkins
16:01:00 <smfr> smfr has joined #css
16:01:24 <Zakim> +djackson
16:01:27 <Zakim> +nvdbleek
16:01:34 <nvdbleek> zakim, mute me
16:01:34 <Zakim> nvdbleek should now be muted
16:01:45 <Rossen> Rossen has joined #css
16:01:57 <Zakim> +[Microsoft]
16:02:17 <Rossen> zakim, microsoft has me
16:02:18 <Zakim> +Rossen; got it
16:02:39 <Zakim> +smfr
16:02:43 <Zakim> +[Microsoft.a]
16:02:59 <leif1> leif1 has joined #css
16:03:00 <Zakim> +SteveZ
16:03:03 <Zakim> +Liam
16:03:11 <smfr> smfr has changed the topic to: http://lists.w3.org/Archives/Public/www-style/2013Apr/0197.html
16:03:29 <TabAtkins_> Good idea, smfr.
16:03:38 <Zakim> + +47.23.69.aaaa
16:03:39 <JohnJansen_> JohnJansen_ has joined #CSS
16:03:45 <leif1> Zakim, aaaa is me
16:03:45 <Zakim> +leif1; got it
16:03:49 <glazou> yeah, I'll do that for future conf calls, thanks smfr
16:03:50 <Zakim> +BradK
16:03:50 <JohnJansen_> Zakim, Microsoft has JohnJansen
16:03:51 <Zakim> +JohnJansen; got it
16:04:11 <smfr> zakim, who's typing noisily?
16:04:11 <Zakim> I don't understand your question, smfr.
16:04:12 <SteveZ> SteveZ has joined #css
16:04:14 <SimonSapin> somone is typing next to their mike
16:04:17 <JohnJansen_> JohnJansen_ has joined #CSS
16:04:29 <JohnJansen_> Zakim, Microsoft has JohnJansen
16:04:29 <Zakim> JohnJansen was already listed in [Microsoft], JohnJansen_
16:04:50 <TabAtkins_> ScribeNick: TabAtkins_
16:04:58 <TabAtkins_> glazou: Three extra agenda items.
16:05:10 <Zakim> +[Apple]
16:05:12 <Zakim> +jdovey
16:05:15 <TabAtkins_> glazou: First from Tab about Varaibles, next from Variables about text-decor, another from Simon Sapin about scinot.
16:05:20 <hober> Zakim, Apple is me
16:05:20 <Zakim> +hober; got it
16:05:33 <TabAtkins_> Topic: Line-breaking proposal
16:05:34 <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0183.html
16:05:43 <Zakim> +fantasai
16:05:53 <TabAtkins_> liam: I'll just go over general purpose.
16:05:54 <koji> koji has joined #css
16:05:55 <Zakim> +[Microsoft.aa]
16:05:56 <arronei> zakim, microsoft has me
16:05:57 <Zakim> +arronei; got it
16:06:08 <TabAtkins_> liam: When you add things like hyphenation, etc. you quickly want to use a lb algorithm that considers more than one line at a time.
16:06:10 <Zakim> +[Microsoft.aaa]
16:06:24 <MaRakow> MaRakow has joined #CSS
16:06:26 <TabAtkins_> liam: It's mor eimportant in print than on the screen, because print has "show-through", where you can see a shadow of what's on the other side of the sheet.
16:06:56 <TabAtkins_> liam: This proposal is to let an author/script say "this piece of text is going to be interactively edited"...
16:07:00 <Zakim> +Bert
16:07:00 <Zakim> +[IPcaller]
16:07:08 <TabAtkins_> liam: I imagine a print processor would set this to "batch" - not edited.
16:07:10 <koji> zakim, [ipcaller] is me
16:07:10 <Zakim> +koji; got it
16:07:21 <MaRakow> zakim, microsoft has me
16:07:21 <Zakim> +MaRakow; got it
16:07:36 <TabAtkins_> liam: You care about editted or not because if you insert a word in the middle of a paragraph, and you use a multi-line linebreaking algo, your text will reflow and your inseration point might move up or down a line.
16:08:00 <TabAtkins_> liam: Some programs handle this by only reflowing when you finish editing, but it's ugly in the meantime.  It's a problem with a long history.
16:08:04 <israelh> israelh has joined #css
16:08:09 <TabAtkins_> liam: Two parts of this proposal:
16:08:17 <TabAtkins_> liam: 1) Say your intent, interactive or batch.
16:08:26 <TabAtkins_> liam: 2) Second, experimentally,s ay waht algorithm to use.
16:09:17 <TabAtkins_> TabAtkins_: Is the "interactive" mode about just editting, or about reflowing as well?
16:09:23 <TabAtkins_> liam: It only matters if the user is in there.
16:09:40 <TabAtkins_> liam: If the text reflows and you care about a particular line of text, that's the same problem you've already got.
16:10:33 <TabAtkins_> TabAtkins_: Okay, next concern - I thought the problem with the TeX algorithm was it being too complex/slow.  Has that changed?
16:11:00 <TabAtkins_> liam: It's slow, yes, but normal text is also really mediocre.  It has really bad cases that you need markup to fix, because it's meant to be manually checked.
16:11:23 <TabAtkins_> liam: Commercial products almost all use an n-line algorithm, that's only slightly slower than the current linear linebreaking (still O(n))0.
16:11:37 <TabAtkins_> liam: With that, you can get quality of linebreaking close to the best commercial.
16:11:48 <TabAtkins_> SimonSapin: Is this related to Adobe's "text balancing" proposal?
16:12:08 <TabAtkins_> stearns: Don't think so.  You can implement text-balacing in a more complex linebreaking algo, but it's not necessary.
16:12:19 <TabAtkins_> glazou: Do you think this is for both print and screen media.
16:12:36 <TabAtkins_> liam: Both.
16:13:08 <TabAtkins_> TabAtkins_: Yeah, I know plenty of people who would want good text on the screen.
16:13:18 <TabAtkins_> glazou: I think the next step is an ED.
16:13:37 <TabAtkins_> liam: I wasn't sure whether the best step was Text 4 or a new draft.
16:13:52 <TabAtkins_> fantasai: I think it should go in Text 4.
16:14:07 <TabAtkins_> fantasai: Text 4 needs to be synced up with Text 3 (the text is old, becasue we branched a while ago).
16:14:14 <TabAtkins_> fantasai: Once it's synced up, we can add things to it.
16:14:28 <TabAtkins_> liam: When you get to this bit, I'll happily help.
16:14:49 <TabAtkins_> ACTION fantasai to add Liam's line-breaking proposal to Text 4.
16:14:49 <trackbot> Created ACTION-553 - Add Liam's line-breaking proposal to Text 4. [on Elika Etemad - due 2013-04-17].
16:14:59 <TabAtkins_> ACTION liam to help fantasai add his line-breaking proposal to Text 4.
16:14:59 <trackbot> Created ACTION-554 - Help fantasai add his line-breaking proposal to Text 4. [on Liam Quin - due 2013-04-17].
16:15:11 <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0750.html
16:15:27 <krit> krit has joined #css
16:15:32 <TabAtkins_> Topic: image-rendering: smooth.
16:15:38 <TabAtkins_> smfr: Don't think there's anything to say here.
16:15:53 <TabAtkins_> TabAtkins_: Yes, I'm fine with the editting.  Was just on vacation last week, so haven't done it yet.
16:15:56 <TabAtkins_> Topic: Variables LC
16:16:22 <glazou> TabAtkins_ { speech-rate: slower; }, please
16:16:43 <fantasai> Rename all the things!
16:16:52 <TabAtkins_> TabAtkins_: I asked for LC a few weeks ago, but jdaggett wanted a new WD first to pull out feedback.  I've done so, and it was useful.  Can I go to LC again now?
16:17:15 <TabAtkins_> SimonSapin: I have some questions about how the Syntax works with Syntax 3, but I can handle that on the list.  It's technical, but I don't think it'll change anything.
16:17:20 <TabAtkins_> glazou: objections?
16:17:40 <TabAtkins_> Bert: I don't object, but I don't think we need it...
16:18:14 <TabAtkins_> RESOLVED: Variables move to LC.
16:18:54 <Zakim> -leif1
16:19:06 <TabAtkins_> Bert: We need to decide as a group what other WGs to talk to.
16:19:14 <krit> krit has joined #css
16:19:19 <TabAtkins_> TabAtkins_: WebApps.
16:19:22 <TabAtkins_> glazou: SVG.
16:19:23 <TabAtkins_> glazou: HTML?
16:19:35 <TabAtkins_> TabAtkins_: Sure, though most of their connection will be through webapps work.
16:20:15 <TabAtkins_> RESOLVED: Inform WebApps, SVG, and HTML about Variables LC.
16:20:19 <glazou> http://lists.w3.org/Archives/Public/www-style/2013Apr/0187.html
16:20:20 <TabAtkins_> Topic: Selectors 4 issues
16:21:06 <TabAtkins_> glazou: Speaking of Selectors, I think some sections of the document (time-based pseudos, for example), need a review from the WG.
16:21:34 <TabAtkins_> fantasai: I brought that up on www-style/at a f2f, but nobody had comments.
16:21:44 <TabAtkins_> glazou: Right.  Everyone, if you have spare cycles, read Selectors 4 and give comments.
16:21:52 <TabAtkins_> fantasai: First issue is about adopting MQ-style invalidation.
16:22:01 <TabAtkins_> fantasai: Currently, any invalid selectors invalidates the entire list.
16:22:11 <TabAtkins_> fantasai: Alternative is to just drop the selector that's invalid (split by commas).
16:22:27 <TabAtkins_> fantasai: But this seems to be quite web-incompatible, because people depend on this behavior.
16:22:41 <TabAtkins_> sylvaing: How do people depend on this?
16:23:07 <TabAtkins_> glazou: Right now there are style rules which are fully invalid because of one selector, and they never noticed the wasted rule.  If you change, it'll start applying and change the page.
16:23:11 <tantek> tantek has joined #css
16:23:47 <Zakim> +leif1
16:23:48 <TabAtkins_> TabAtkins_: And there is some history of people using prefixed selectors in the selector list as a browser hack, and this would change the behavior they're depending on.
16:23:59 <TabAtkins_> RESOLVED: Do not adopt MQ-style invalidation for Selectors.
16:24:12 <TabAtkins_> fantasai: Next issue is whether id selectors should accept all hash tokens, or just hash tokens with an ident value.
16:24:19 <krit> krit has joined #css
16:24:22 <TabAtkins_> fantasai: For example, #1 is a valid hash token, but not a valid id selector.
16:24:44 <TabAtkins_> fantasai: HTML now, I believe, allows ids that start with a number.
16:24:47 <glazou> Regrets: dbaron
16:25:05 <tantek> it does
16:25:55 <TabAtkins_> glazou: Do you think this has compat impact?
16:26:01 <TabAtkins_> TabAtkins_: I suspect this is used much less.
16:26:42 <krit> zakim, me is with rhauck
16:26:42 <Zakim> +krit; got it
16:26:44 <TabAtkins_> arronei: Isn't this the same case as the last one?  Groups could be invalid currently that would become valid.
16:26:46 <Zakim> +Tantek
16:26:53 <tantek> Zakim, mute Tantek
16:26:53 <Zakim> Tantek should now be muted
16:27:40 <TabAtkins_> glazou: If HTML now allows non-ident selectors, then this is a needed hange.
16:27:49 <TabAtkins_> SimonSapin: Any way to assess the impact of this change?
16:27:56 <TabAtkins_> [discussion about using Google resources for this]
16:28:07 <TabAtkins_> hober: It's hard to say without data.
16:28:25 <tantek> Zakim, unmute Tantek
16:28:25 <Zakim> Tantek should no longer be muted
16:28:27 <TabAtkins_> Rossen: We'd have to run a query and see how many hits we have.  Without data, we're uncomfortable committing.
16:28:44 <TabAtkins_> tantek: I don't have any hard data, but I can give you anecdotally...
16:29:06 <TabAtkins_> tantek: One fo the things that happens in mediawiki pages is that whatever you use as a heading/subheading gets turned into an id.
16:29:15 <TabAtkins_> tantek: So if you have a heading start with a number, that's the id.
16:29:32 <TabAtkins_> tantek: One major complaint I hear is headings that are just numbers.
16:29:41 <TabAtkins_> tantek: Whether they're getting styled or not, I have no idea.
16:30:50 <TabAtkins_> TabAtkins_: I can confirm that browsers are pretty consistenet about allowing full hash tokens in Quirks mode, but only restricted ident hashes in Standards mode.
16:31:09 <TabAtkins_> glazou: Two members of the WG are asking for data here.
16:31:20 <TabAtkins_> ACTION tab to look for data on non-ident hash usage.
16:31:20 <trackbot> Created ACTION-555 - Look for data on non-ident hash usage. [on Tab Atkins Jr. - due 2013-04-17].
16:31:21 <glazou> http://www.w3.org/Style/CSS/Tracker/issues/317
16:32:00 <TabAtkins_> fantasai: child-index pseudos (:nth-child(), etc.) don't work on unparented elements, such as :root.  This makes sense there, because there's not much sense in having them apply to root, but there's alow the issue of documetn fragments.
16:32:15 <TabAtkins_> fantasai: (the top-level elements in a document fragment wont' match :nth-child())
16:32:36 <TabAtkins_> fantasai: The only argument I've heard against it is that the word "child" is in the name, so it should only apply to children.
16:32:48 <TabAtkins_> glazou: We deal only with elements in CSS.
16:33:31 <fantasai> [tab explains things wrt DocumentFragment case becoming more common, shadow dom, etc]
16:34:00 <BradK> BradK has joined #CSS
16:34:16 <TabAtkins_> fantasai: Ideally in the beginning we would have called it :nth-sibling...
16:34:19 <fantasai> fantasai: We wouldn't be having this argument if it were called :nth-sibling
16:34:34 <fantasai> glazou: Then let's add a new pseudo-class
16:34:40 <SimonSapin> not 1 new pseudo-classes, 11 of them
16:34:49 <tantek> FYI: regarding ID selectors that start with numbers, we do test for the non-support - in the CSS 2.1 test suite: http://test.csswg.org/suites/css2.1/20110323/html4/id-selector-005.htm
16:34:54 <TabAtkins_> glazou: I would prefer a new pseudoclass.
16:34:56 <fantasai> TabAtkins: It's silly and confusing to add new pseudo-class that means exactly the same thing except when selecting root or DocumentFragment elements
16:35:06 <tantek> that's why we have interop among browsers for non-support of ID selectors that start with a number.
16:35:59 <tantek> Zakim, mute tantek
16:35:59 <Zakim> Tantek should now be muted
16:36:27 <TabAtkins_> glazou: I don't think it should apply to root.
16:36:49 <TabAtkins_> TabAtkins_: I'm fine with that, if it applies to docfrags and shadow dom and the like.
16:37:58 <TabAtkins_> glazou: I could live with an addition to the shadow DOM spec that says shadow roots act like a parent.
16:38:12 <TabAtkins_> TabAtkins_: Then we'd have to add the same thing to DOM for docfrags.
16:38:44 <TabAtkins_> The pseudo-classes defined in this section select elements based on their index in their parent's list of children (or, if they have no parent, by their index in the list of them and their siblings).
16:39:16 <SimonSapin> can DocumentFragment contain multiple "root" elements?
16:39:30 <oyvind> yes
16:39:36 <TabAtkins_> no. ^_^
16:39:51 <TabAtkins_> Bert: What does :root match in document fragments?
16:39:56 <SimonSapin> … ?
16:40:03 <TabAtkins_> TabAtkins_: Nothing, I believe.  There's no root element in a docfrag.
16:40:18 <oyvind> well, a documentfragment can have multiple child nodes
16:40:39 <oyvind> I figured that was what SimonSapin meant :)
16:40:47 <SimonSapin> oyvind: yes
16:40:55 <TabAtkins_> MINUTE BANKRUPTCY
16:40:59 <SimonSapin> in that case it makes sense for :nth-child() to apply
16:41:06 <TabAtkins_> Bert: I'm trying to find the similarities between document and docfrag.
16:42:14 <TabAtkins_> Bert: If we do this for :nth-child, maybe we shoudl do it for :root too.
16:42:51 <TabAtkins_> TabAtkins_: Nah, no need. :nth-child() is being redefined into just based on siblings.  :root is still about document roots, which docfrags don't have.
16:43:00 <TabAtkins_> glazou: I'm okay with this change, though I don't like it.
16:43:47 <TabAtkins_> RESOLVED: :nth-child()/etc don't require a parent - they're based on siblings.
16:44:14 <TabAtkins_> antonp: Can we have a note saying that the name doesn't make much sense anymore?
16:44:16 <TabAtkins_> fantasai: Yes.
16:44:19 <Zakim> +SteveZ.a
16:44:29 <Zakim> -SteveZ
16:44:44 <TabAtkins_> Bert: It seems that your addition makes :first-child apply to the root element, which wasn't the case before.
16:45:55 <TabAtkins_> Bert: So should there be text saying that it only applies to docfrags, not roots?
16:45:56 <tantek> Zakim, who was making noise?
16:45:56 <Zakim> I don't understand your question, tantek.
16:46:07 <glazou> thanks for attending liam
16:46:10 <Zakim> -Liam
16:46:11 <liam> thank you!
16:46:21 <TabAtkins_> TabAtkins_: I don't think that's necessary.  Incidence of :first-child selectors that accidentally hit the root should be so low as to be effectively zero.
16:46:46 <Zakim> -SimonSapin
16:47:05 <TabAtkins_> fantasai: We'll come back with final phrasing so everyone can comment.
16:47:32 <TabAtkins_> Bert: I'm not comfortable with changing things for existing documents.  Probably rare for HTML, but there are many other kinds of documents.
16:47:48 <Zakim> +SimonSapin
16:48:12 <TabAtkins_> Bert: Ther'es a use-case for fragments, but not for normal documents.
16:48:56 <glazou> https://www.w3.org/Style/CSS/Tracker/issues/318
16:48:59 <TabAtkins_> TabAtkins_: I'm fine with discussing on the list whether :root and :nth-child/etc should be mutuallye xclusive.
16:49:02 <TabAtkins_> Bert: That's fine.
16:49:15 <TabAtkins_> fantasai: Next issue is about the specificity of :matches() and :not().
16:49:25 <TabAtkins_> fantasai: Currently the specificity of :matches is the spec. of the most specific selector inside it.
16:49:55 <TabAtkins_> fantasai: proposal was to make it the most specifci selector that actually matched, so that it truly becomes syntactic sugar for the combinatorial-explosion of multiple selectors.
16:50:05 <TabAtkins_> fantasai: I think there's no reason not to take this, except that it's slightly annoying to implement.
16:50:18 <TabAtkins_> SimonSapin: I brought up that it's not possible to do this when converting selectors to XPath.
16:50:50 <glazou> https://www.w3.org/Style/CSS/Tracker/issues/319
16:50:54 <TabAtkins_> TabAtkins_: Yeah, while XPaqth and Selectors are very similar techs, they both ahve edge-cases that can't be converted.  It's fine, I think.
16:51:15 <TabAtkins_> RESOLVED: Changed specificy of :matches()/:not() to the specificity of the actual matched selector.
16:51:21 <SimonSapin> SimonSapin: but we should still do it because even in Selectors 3 some corner cases can (probably) not be expressed in XPath
16:51:28 <TabAtkins_> fantasai: Next topic, :empty is pretty useless for most people.
16:51:49 <TabAtkins_> fantasai: It only selects elements with no nodes, which means that whitespace makes it not match, even though that gets collapsed away in HTML.
16:52:17 <TabAtkins_> fantasai: We can redefine :empty to also match if the element is only filled with whitespace, or we can make a new pseudoclass for it.
16:52:20 <TabAtkins_> glazou: I recommend the latter.
16:52:26 <TabAtkins_> fantasai: Is there a use-case for the former?
16:52:47 <tantek> we have a test for :empty that checks to make sure it is NOT applied to an element with only white-space: http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current/html/tests/css3-modsel-151.html
16:52:49 <TabAtkins_> Bert: Something with a space isn't empty.
16:53:01 <tantek> therefore we have interop on it in current form
16:53:06 <TabAtkins_> glazou: I used :empty as it is for something in Gecko.
16:53:27 <tantek> so changing it would break all browsers
16:53:33 <TabAtkins_> fantasai: So what would we name it?
16:53:37 <TabAtkins_> Bert: :blank?
16:53:40 <tantek> :space
16:53:45 <glazou> tantek, yes
16:53:47 <fantasai> tantek, it's potentially empty
16:53:58 <tantek> space is pretty empty ;)
16:54:07 <TabAtkins_> fantasai: I thought we might use that for empty inputs...
16:54:13 <SimonSapin> <div><div></div></div>
16:54:20 <TabAtkins_> SimonSapin: Would this select elements with other empty children?
16:54:35 <TabAtkins_> fantasai: No, only elements that contain nothing or insignificant whitespace.
16:54:40 <tantek> :visibly-empty
16:54:45 <TabAtkins_> glazou: What about :almost-empty?
16:54:47 <plinss> :mostly-empty
16:54:56 <leif1> :insignificant
16:54:59 <Rossen> :just-about-empty
16:55:03 <TabAtkins_> :this-element-intentionally-left-blank
16:55:06 <BradK> :good-as-empty
16:55:30 <tantek> :empty-or-space
16:55:35 <TabAtkins_> glazou: We agree on the selector, but still need to come up with a good name.
16:55:39 <jdovey> :quiet
16:56:14 <Rossen> :boring
16:56:15 <tantek> :silent
16:56:17 <fantasai> szilles: :void
16:56:20 <TabAtkins_> RESOLUTION: Define a new selector that matches empty or insignificatn whitespace.
16:56:24 <BradK> :white-space
16:56:28 <fantasai> TabAtkins: Confusing because void refers to what :empty currently means
16:56:39 <glazou> https://www.w3.org/Style/CSS/Tracker/issues/320
16:56:56 <TabAtkins_> fantasai: :matches() was always intended to be able to accept complex selectors (with combinators).
16:57:12 <TabAtkins_> fantasai: Right now the Selectors 4 draft has explicitly excluded them, due to performance concerns.
16:57:23 <TabAtkins_> fantasai: But this confuses everybody, because they want complex selectors, and ask for new features.
16:57:48 <TabAtkins_> fantasai: Also, the performance concerns don't appyl to batch processors or Selectors API - only to CSS Selectors.
16:58:18 <TabAtkins_> fantasai: So the idea is to define "fast" and "complete" profiles.  "fast" is only compound selectors in :matches()/:not(), "complete" is everything.
16:58:26 <TabAtkins_> fantasai: We want to mark this as at-risk.
16:58:38 <TabAtkins_> fantasai: The alternative is to just include complex selectors and mark the whole thing as at-risk.
16:58:48 <TabAtkins_> fantasai: We just want to find out what implementations actually want to do.
16:59:08 <TabAtkins_> glazou: I have a problem.  It implies that after CR we may have shipped impls of either profile, so inconsistency for the web.
17:00:07 <TabAtkins_> glazou: I understand you have the two profiles for Selectors API.
17:00:10 <Zakim> -Plh
17:00:53 <TabAtkins_> glazou: I'd prefer that the fast profile be explicitly limited to CSS Selectors, and complete be for everything.  Then we can decide to open up the profiles later.
17:01:20 <TabAtkins_> SimonSapin: I'm concerned that the same impl could match different profiles based on the use (print vs live, etc.)
17:01:24 <TabAtkins_> fantasai: I'm fine with this.
17:01:33 <TabAtkins_> fantasai: I just want to reduce confusion in the spec.
17:01:56 <TabAtkins_> plinss: If we later allow browser to implement the complete profile, there will still be a transitional state, so I'm not sure what we buy here.
17:02:47 <TabAtkins_> fantasai: If everyone's ready for it, there will be a short transition period, as opposed to the current undefined transition.
17:03:16 <TabAtkins_> glazou: What if we just mark the complete profile as being informative, with it being defined normatively in the future?
17:03:27 <TabAtkins_> TabAtkins_: I'm opposed to that, because I want Selectors API to pick it up.
17:03:32 <Zakim> -SteveZ.a
17:03:33 <Zakim> -hober
17:03:34 <Zakim> -rhauck
17:03:34 <Zakim> -[Microsoft.a]
17:03:34 <Zakim> -Tab_Atkins
17:03:35 <Zakim> -nvdbleek
17:03:35 <Zakim> -[Microsoft]
17:03:35 <Zakim> -sgalineau
17:03:36 <Zakim> -[Microsoft.aa]
17:03:36 <Zakim> -glazou
17:03:36 <Zakim> -leif1
17:03:37 <Zakim> -jdovey
17:03:37 <Zakim> -fantasai
17:03:37 <Zakim> -smfr
17:03:39 <Zakim> -Stearns
17:03:39 <Zakim> -BradK
17:03:39 <Zakim> -djackson
17:03:39 <Zakim> -SimonSapin
17:03:40 <Zakim> -koji
17:03:40 <Zakim> -Tantek
17:03:41 <TabAtkins_> glazou: I'm okay with that.
17:03:41 <Zakim> -[Microsoft.aaa]
17:03:46 <Zakim> -Bert
17:03:49 <Zakim> -antonp
17:03:52 <Zakim> -plinss
17:03:54 <leif1> leif1 has left #css
17:04:02 <TabAtkins_> RESOLVED: Accept the two profiles of Selectors, with "fast" for CSS Selectors and "complete" for Selectors API.
17:04:25 <BradK> BradK has left #css
17:04:27 <Zakim> -glenn
17:04:28 <Zakim> Style_CSS FP()12:00PM has ended
17:04:28 <Zakim> Attendees were glazou, sgalineau, plinss, Stearns, rhauck, glenn, antonp, SimonSapin, Plh, Tab_Atkins, djackson, nvdbleek, Rossen, smfr, [Microsoft], SteveZ, Liam, +47.23.69.aaaa,
17:04:28 <Zakim> ... leif1, BradK, JohnJansen, jdovey, hober, fantasai, arronei, Bert, koji, MaRakow, krit, Tantek
17:11:02 <abucur> abucur has joined #css
17:16:19 <rhauck> rhauck has joined #css
17:21:06 <TabAtkins_> TabAtkins_ has joined #css
17:32:23 <isherman-book> isherman-book has joined #css
17:37:12 <zcorpan> zcorpan has joined #css
17:59:43 <rhauck> rhauck has joined #css
18:01:19 <isherman-book> isherman-book has joined #css
18:29:58 <SimonSapin> SimonSapin has joined #css
18:38:04 <isherman-book> isherman-book has joined #css
18:45:25 <cabanier> cabanier has joined #css
19:06:27 <Zakim> Zakim has left #css
19:07:00 <glenn> glenn has joined #css
19:28:30 <zcorpan> zcorpan has joined #css
19:30:27 <florian> florian has joined #css
20:00:09 <zcorpan> zcorpan has joined #css
20:12:45 <isherman-book> isherman-book has joined #css
20:34:50 <darktears> darktears has joined #css
20:46:43 <tantek> tantek has joined #css
20:46:52 <cabanier> cabanier has joined #css
20:57:31 <tantek> tantek has joined #css
21:33:46 <glenn> glenn has joined #css
21:44:41 <glenn_> glenn_ has joined #css
21:45:05 <glenn> glenn has joined #css
21:47:25 <zcorpan> zcorpan has joined #css
22:01:13 <glenn_> glenn_ has joined #css
22:01:53 <rhauck> rhauck has joined #css
22:23:04 <danielfilho|w> danielfilho|w has joined #css
22:30:44 <cabanier> cabanier has joined #css
22:32:43 <danielfilho|w> danielfilho|w has joined #css
22:44:13 <rhauck> rhauck has joined #css
22:45:45 <florian> florian has joined #css
22:53:32 <glenn> glenn has joined #css
23:56:09 <isherman-book> isherman-book has joined #css