See also: IRC log
<glazou> honestly, the worst in ten years
<sgalineau> Zakim aaaa is me
<glazou> wow, lights going down, almost power outage
<glazou> if you see me leave the channel, you'll know why
<BradK> Driving in about a minute. Won't look at screen.
<BradK> Muted too, but listening.
<jerenkrantz_> Zakim: aacc is me
<BradK> I don't see my 650 number
<glazou> florian, same here, you can probably hear the thunder in background from my microphone
<dael> zakim: aadd is me
<SimonSapin> Zakim: ??P69 is probably me
<florian> [IPcaller] is several people, including me, but I was muted on my side
<leif> done :)
<molly> hahaha
<glazou> plh, well I don't ARRRRRRGLL
<SimonSapin> what’s the status on background-position-x/y?
<antonp> ScribeNick: antonp
<sgalineau> Zakim [Microsoft] has JohnJansen
<dbaron> is somebody scribing?
<JohnJansen> I guess my phone is angry with Zakim.
plh: Chris is sick and Bert is on
vacation. So I'm stepping in as publishing rep.
... I hope tomorrow we will be up to date
... I don't look at the technical issues, just the
administrative ones
SimonSapin: shortnames - we discussed in Tokyo
plh: I think there is an issue in
this group about shortnames
... I found inconsistency
plinss: Issue about latest version links vs current version links?
plh: yes
plinss: Also we'll talk about the preprocessor
Elika sent regrets, and comments to the list
dbaron: I'd rather wait for Elika I think
<plinss> http://www.w3.org/mid/51C15ECC.2030309@inkedblade.net
plinss: OK
Elika and Koji would like to take over as editors.
glazou: fine
RESOLUTION: Koji, Elika and Jim as editors
<stearns> http://lists.w3.org/Archives/Public/www-style/2013Jun/0332.html
leif: <summarizes issue>
<JohnJansen> * JohnJansen is not able to dial in either.
<MaRakow> Also can't dial in
<tantek> plh, being told
<tantek> The number or code you have dialed is incorrect. Please check the number or code and try again. Message 7. Switch 521.
<tantek> have been trying for
past 10 min
..: tantek was concerned about whether the properties (?nav-up,
nav-down, nav-right, and nav-left ?) were
implementable/testable
... we have a test suite to demonstrate they "work"
... so, we conclude we only want to drop nav-index not those
other four
hober Are you ok with adding them to css4?
<tantek> Am totally ok adding them to CSS4
leif: we think they're good to add to css3
<tantek> hence I've put them on the wiki page for CSS4-UI
<molly> I think they're fine wherever they go so long as they go somewhere #a11y
sylvain (earlier)#: I'd rather not resolve without the editor on the call
<tantek> http://wiki.csswg.org/spec/css4-ui
<dael> I'll drop the call if would help. I'm non-critial.
<tantek> http://wiki.csswg.org/spec/css4-ui#nav-properties
<SimonSapin> florian: (?) we can’t hear you
<florian> I'll type it
<tantek> I'm opposed to putting them in CSS3-UI until there's more work done on the part of those that want them like submitting the test cases for directional nav-properties.
<tantek> If that's done and the download simulator shows it clearly working, I'd strongly consider keeping directional nav-* properties in CSS3-UI but *at risk*.
leif: I'm ok with the idea that if we don't do the work then we don't include them in css3-ui
<molly> Tantek: is your
concern the type of implementations or lack of them?
..: but I'd like not to make that decision now before we've
tried
plinss: The props are there but at risk
<tantek> That is, IF we have contributed test cases, AND *ONE* implementation that is easily downloadable/testable, THEN I think it is correct to include them in CSS3-UI but *AT RISK*
<florian> It was argued that
these are mainly used outside of the open web. But I don't
think that's relevant. If it was in conflict with stuff on the
open web, that would be a point, but there is not conflict I
know of, and there is nothing in our charter that restricts CSS
to open web only. Importantly, if walled garden people are
increasingly adopting our technology stack, we try to
accomodate them, to limit the risk of them forking into
something incompatible
..: so what specifically are you asking for?
leif: The edits haven't happened yet, but they were resolved dropped.
plinss: ok
<tantek> asking for: contribute the test cases per the existing process in CSSWG for contributing test cases
?: regarding test cases, doesn't tantek's objection disappear if you can get simulator,implementation reports, tests our
leif: yes
<florian> agree with Sylvain
<tantek> http://wiki.csswg.org/test#contributing
sylvain(?): I think your request to undo the previous resolution is reasonable; sounds like it was based on incorrect info
plinss: I agree
<tantek> The reason I'm skeptical about this is that none of this has happened in the years that directional nav was previously in CR.
<sgalineau> tantek, it has happened; we didn't know until now that it did
<tantek> It wasn't based on incorrect info, it was based on the info at the time.
<tantek> Now we have newer information
<sgalineau> i didn't say incorrect, i said incomplete
<tantek> We can re-assess once the test cases have been contributed.
leif: afaict there's limited functionality, not much "space" to test. Think it's interoperable
<sgalineau> test cases are required to exit CR
<florian> Level 3 at risk sounds good to me
plinss: any objections to leaving it as risk (instead of removing)?
<tantek> currently they're slated for removal
molly: what does "at risk" actually mean?
<tantek> I'll hold off on those edits if there's a commitment for contributing test cases within a reasonable time frame
plinss: We can drop them without regressing from CR to LC
<sgalineau> tantek, yes the are. based on incomplete info.
<florian> "at risk" means "at risk of being dropped or pushed back if there are no implementations"
<tantek> so any such resolution should include a time commitment for contributing the tests
<tantek> retrying zakim
plinss: acknowledge tantek's request
<florian> There are already 2 implementations, as Leif said: presto and webkit
tantek: If we're able to get even one implementation and see it working then that's good enough for leaving "at risk".
plinss: was the webkit implementation done by opera as well
leif: probably not, but I'll get that confirmed
plinss: I'm not hearing any objections to leaving them in "as risk"
tantek: I'd like a time commitment for submitting tests
plinss: well, that's the rec track right?
tantek: I'd like to pick a timeframe. I'm willing to be patient, but would like to hear a commitment
leif: I think we can do that within a month
tantek: OK let's wait a month. Then if no tests etc we'll drop them
RESOLUTION: leave these features at risk in level 3
ACTION leif to submit tests etc
<trackbot> Created ACTION-565 - Submit tests etc [on Leif Arne Storset - due 2013-06-26].
<florian> My mike doesn't work, so I'll type it. We resolved to make "not", "or", "and", and "only" invalid (rather than unknown) media types. I made the change in MQ level 4 and posted a few tests: http://lists.w3.org/Archives/Public/www-style/2013Jun/0270.html
<florian> This looks like something that should cause an errata for MQ3, but I want the group's confirmation, and I don't know the process
http://lists.w3.org/Archives/Public/www-style/2013Jun/0270.html
SimonSapin: Goes back to Tokyo discussion
<SimonSapin> florian: we should errata level 3 if we agree on the changes
glazou: I think we should do the changes
<florian> I'd like the group to tell me if the change I put in level 4 is fine, and if yes, someone explain the process
<florian> that's the only errata
plinss: we probably don't have any errata yet for mq3?
<florian> is there?
<dbaron> http://www.w3.org/Style/2012/REC-mediaqueries-20120619-errata.html
dbaron: There's an erratum in the errata doc
<florian> thanks for reminding me of the other errata
plh: Just tell me what I need to
put there, and I'll put it
..: the doc isn't normative until it's folded into a new
edition
plinss: you mean an PER of the spec?
plh: correct
<SimonSapin> the spec header says that errata are normative …
<florian> I don't think there is a rush
<florian> but I'd like implementers' opinion
plh: so do we fold into level 3? Or wait until level 4
<plh> btw florian, your tests don't pass on IE10 either
<florian> +1 to dbaron
<florian> I'll try and remember
<glazou> +1
dbaron: I'm inclined to say, stick it in the errata and wait to see if any other errata crop up in the next 6 months
<dbaron> dbaron: And then hopefully we'll remember to come back in 6 months.
plinss: so we'll add it to the errata. Who will take that action?
<florian> I've written if for level 4
<florian> I think the same phrasing applies to level 3
<florian> I'd like feedback
plh: I'm happy to add it - but someone needs to send the text
ACTION florian to send relevant prose to plh
<trackbot> Created ACTION-566 - Send relevant prose to plh [on Florian Rivoal - due 2013-06-26].
<tantek> leif, florian, I couldn't find the URL to the Webkit-simulator with nav-* properties
<tantek> could you provide URL to email or just the simulator directly?
SimonSapin: I'd like to go back
to how we do changes
..: Does a level 4 completely replace level 3? Or do we need to
fix level 3?
...: when level 4 becomes a REC
?
plh: I don't remember what we do to the level 3 spec in that case. Add a note to readers?
<florian> we don't have any level 4 rec yet, do we?
plinss: we don't have many level 4 yet
SimonSapin: <summarizes issue>
http://lists.w3.org/Archives/Public/www-style/2013Jun/0268.html
hober (?): I don't think we should do this until we actually have a module which requires it
<florian> There were two parts proposed about it, one about forward compatibility, one about an actual used of the ! for new stuff. I am ok with the first stuff, I think the later is interesting but premature
molly: I'm really concerned about this. There's already misuse and understanding due to the existing syntax choice
<dbaron> dbaron (after hober): I think we want to make the values of variables general now.
hober: until we have a concrete ident-after-! it would be premature to generalize the syntax
SimonSapin: but we need to think
about compat
... <explains>
plinss: Didn't we already resolve as invalid, variables with !important?
SimonSapin: <replies>
<SimonSapin> SimonSapin: we want new stuff to be invalid in older UAs
<SteveZ> Doesn't this also simplify parsing of the variable value?
<SimonSapin> dbaron, I want var-foo: red !type(color); to be invalid rather than have the value be "red !type(color)"
<tantek> +1 to Molly's and Hober's objections/concerns.
hober: I don't see why we need to generalize this so early, but I'm not going to formally object or whatever
<dbaron> hober: we can just disallow ! in variables other than !important so that we can extend it later, without extending it now
<florian> I approve of the proposal
<dbaron> SimonSapin: That's exactly my proposal.
glazou: looking at the example, I agree with the proposal
<SteveZ> +1 for Simon's proposal
<c_palmer> as long as !important is still valid for a variable, I'm for it
plinss: any objections to the proposal?
<glazou> yay SimonSapin
RESOLUTION: proposal accepted
<SimonSapin> RESOLVED: top-level ! is invalid in Custom Properties
<SimonSapin> … allowing for future extensions with similar syntax to !important
<glazou> ScribeNick: molly
<stearns> http://lists.w3.org/Archives/Public/www-style/2013Jun/0245.html
Alan: Describes issue
David: I think I'd have interest if it were clearly defined but I need to understand more
Alan: I'll reply to thread with a more complete definition
David: This is good for me, but
in the spec would need to be more detailed
... I'm okay with it
Peter: Thoughts/Objections?
<dbaron> (we're discussing just elementsFromPoint() so far)
Alan: Will add some text for more information, and wait until we have implementations of elementesFromPoint()
Peter: Seems fair enough: opinions?
<dbaron> Alan: For the second part (pointer-events: paint-order), I think it makes sense to wait until we have implementations of elementsFromPoint()
Peter: Resolved
no objection
<plinss> RESOLVED: add elementsFromPoint() to cssom-view
<plinss> ACTION: stearns to propose text for elementsFromPoint [recorded in http://www.w3.org/2013/06/19-css-minutes.html#action01]
<trackbot> Created ACTION-567 - Propose text for elementsFromPoint [on Alan Stearns - due 2013-06-26].
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Jun/0240.html
Glazou: Describing issue
... Two possibilities - first if multiple, only last wins
OR
didn't catch that
<SimonSapin> glazou: or all of them match
<dbaron> I'd prefer either (a) or (c) in http://lists.w3.org/Archives/Public/www-style/2013Jun/0240.html ; I don't like (b).
Fantasai: I think it makes more sense if all of them match
Glazou: it's an implementation change so I want to hear from implementors
David: I might be missing something here
<SimonSapin> s/leaverou/leaverou/ ?
Glazou and Dbaron - syntactic sugar discussion
Peter: Is anyone implementing yet?
<dbaron> Lea: It's just syntactic sugar.
Glazou: put in selectors4
<dbaron> dbaron: It might (depending on implementation) require implementations to remap the syntax, which is a bit of a pain, but hard to know.
Peter: Resolved
<plinss> RESOLVED: multiple subject selectors allowed and all match
RESOLVED place Multiple Subject Indicator matching in Selectors Level 4
<plinss> http://lists.w3.org/Archives/Public/www-style/2013Jun/0097.html
Discussing Cross-Origin Style Sheets
<dbaron> dbaron: I think people who are interested should go review the change.
Peter: Anyone else?
<dbaron> Simon: Please look at the issue in agenda item (A) on the mailing list.
<SimonSapin> A. [css-backgrounds] Painting area and 'background-attachment: local'
<SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Jun/0276.html
<antonp> Thanks for taking over the scribing, Molly! My line was terrible; couldn't hear half the group
<SimonSapin> dbaron: looked at Syntax yet ? :)
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/?:/hober/ Succeeded: s/hober/?/ Succeeded: s/hober/sylvain (earlier)#/ Succeeded: s/confirms/confirmed/ Succeeded: s/RESOLUTION: /RESOLVED: / Succeeded: s/ED/PER/ Succeeded: s/dbaron:/dbaron,/ WARNING: Bad s/// command: s/Fantasai/leaverou/ ? Succeeded: s/Fantasai/leaverou/ Found ScribeNick: antonp Found ScribeNick: molly Inferring Scribes: antonp, molly Scribes: antonp, molly ScribeNicks: antonp, molly WARNING: No "Present: ... " found! Possibly Present: Alan Apple BradK David Fantasai IPcaller JohnJansen Krit Lea Liam MaRakow Microsoft Molly_Holzschlag Ms2ger P11 P61 P69 Peter Rossen ScribeNick Simon SimonSapin SteveZ aaaa aacc aadd aaee abucur antonp arno arronei_ c_palmer cabanier cbiesinger dael darktears dbaron ed florian glazou hober israelh jerenkrantz_ leif logbot molly nvdbleek oyvind plh plinss sgalineau shezbaig_wk smfr stearns tantek tantek_ tobie trackbot zcorpan You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 19 Jun 2013 Guessing minutes URL: http://www.w3.org/2013/06/19-css-minutes.html People with action items: stearns[End of scribe.perl diagnostic output]