19 Jun 2013

See also: IRC log


antonp, molly


<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

css-text-3 Issues

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

CSS Ruby Editors

Elika and Koji would like to take over as editors.

glazou: fine

RESOLUTION: Koji, Elika and Jim as editors

Revive direction focus nav properties

<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

Errating MQ3


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

Extend !important to !<anything>*

SimonSapin: <summarizes issue>


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

Paint order

Alan: Describes issue

elementsFromPoint() and pointer-events:paint-order

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

Multiple Subject Indicators

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 ? :)

Summary of Action Items

[NEW] ACTION: stearns to propose text for elementsFromPoint [recorded in http://www.w3.org/2013/06/19-css-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013-06-19 17:00:31 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/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]