- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 03 Jul 2013 00:50:40 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Koji, fantasai and Jim Dovey as editors of CSS Ruby
- RESOLVED: leave directional nav-* properties at risk in level 3
- Discussed errata'ing MQ3
- RESOLVED: top-level ! is invalid in Custom Properties
- RESOLVED: add elementsFromPoint() to cssom-view
- RESOLVED: multiple subject selectors allowed and all match, Selectors L4
- Please review Cross-Origin Style Sheets thread at
http://lists.w3.org/Archives/Public/www-style/2013Jun/0097.html
- Please review css3-background issue on background-attachment: local
http://lists.w3.org/Archives/Public/www-style/2013Jun/0276.html
====== Full minutes below ======
Present:
Rossen Atanassov
Shezan Baig
David Baron
Tantek Çelik
Justin Erenkrantz
Elika Etemad
Sylvain Galineau
Daniel Glazman
Molly HolzSchlag
Dael Jackson
John Jansen
Brad Kemper
Philippe Le Hégaret
Peter Linss
Edward O'Connor
Christopher Palmer
Anton Prowse
Matt Rakow
Florian Rivoal
Simon Sapin
Dirk Schulze
Alan Stearns
Lea Verou
Steve Zilles
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Jun/0357.html
Scribe: AntonP
Administrative
--------------
plh: Chris is sick and Bert is on vacation. So I'm stepping in as
publishing rep.
plh: I hope tomorrow we will be up to date
plh: 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
plh: I found inconsistency
plinss: Issue about latest version links vs current version links?
plh: yes
plinss: Also we'll talk about the preprocessor
Text Issues
-----------
fantasai sent regrets, and comments to the list
dbaron: I'd rather wait for fantasai I think
<plinss> http://www.w3.org/mid/51C15ECC.2030309@inkedblade.net
http://lists.w3.org/Archives/Public/www-archive/2013Jul/0010.html
plinss: OK
CSS Ruby
--------
fantasai and Koji would like to take over as editors.
glazou: fine
RESOLVED: Koji, fantasai and Jim Dovey as editors
nav-* properties
----------------
TOPIC: Revive direction focus nav properties
<stearns> http://lists.w3.org/Archives/Public/www-style/2013Jun/0332.html
leif: <summarizes issue>
leif: tantek was concerned about whether the properties (?nav-up,
nav-down, nav-right, and nav-left ?) were implementable/testable
leif: we have a test suite to demonstrate they "work"
leif: 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
<tantek> hence I've put them on the wiki page for CSS4-UI
<tantek> http://wiki.csswg.org/spec/css4-ui
<tantek> http://wiki.csswg.org/spec/css4-ui#nav-properties
leif: we think they're good to add to css3
<molly> I think they're fine wherever they go so long as they go
somewhere #a11y
hober: I'd rather not resolve without the editor on the call
<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*.
<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*
<molly> Tantek: is your concern the type of implementations or lack of them?
<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.
leif: I'm ok with the idea that if we don't do the work then we don't
include them in css3-ui
leif: but I'd like not to make that decision now before we've tried
plinss: The props are there but at risk
plinss: 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
<tantek> http://wiki.csswg.org/test#contributing
sylvain: regarding test cases, doesn't tantek's objection disappear if
you can get simulator, implementation reports, tests
leif: yes
sylvain: I think your request to undo the previous resolution is reasonable;
sounds like it was based on incorrect info
<florian> agree with Sylvain
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)?
molly: what does "at risk" actually mean?
plinss: We can drop them without regressing from CR to LC
<florian> "at risk" means "at risk of being dropped or pushed back if
there are no implementations"
<tantek> currently they're slated for removal
<tantek> I'll hold off on those edits if there's a commitment for
contributing test cases within a reasonable time frame
<sgalineau> tantek, yes the are. based on incomplete info.
<tantek> so any such resolution should include a time commitment for
contributing the tests
<tantek> retrying zakim
<Zakim> +Tantek
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".
* shezbaig_wk wonders how nav properites work in dynamic layouts like
flexbox where things can move around?
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
RESOLVED: leave these features at risk in level 3
ACTION leif to submit tests etc
<trackbot> Created ACTION-565
<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?
<leif> tantek: It's http://www.smarttv-alliance.org/Markets/Developers.aspx
<leif> (warning: 1 GB download)
Errataing Media Queries 3
-------------------------
<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
<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
<plh> btw florian, your tests don't pass on IE10 either
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
plh: 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
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: And then hopefully we'll remember to come back in 6 months.
<florian> I'll try and remember
<florian> +1 to dbaron
<glazou> +1
plinss: so we'll add it to the errata. Who will take that action?
<florian> I've written it 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
SimonSapin: I'd like to go back to how we do changes
glazou plh we never deprecate anything, we have levels not versions ahem :-)
SimonSapin: Does a level 4 completely replace level 3? Or do we need
to fix level 3?
SimonSapin: 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>
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.
dbaron: I think we want to make the values of variables general now.
<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
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: 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
hober: we can just disallow ! in variables other than !important so
that we can extend it later, without extending it now
SimonSapin: That's exactly my proposal.
<florian> I approve of the 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
RESOLVED: top-level ! is invalid in Custom Properties
<SimonSapin> … allowing for future extensions with similar syntax to
!important
pointer-events
--------------
Scribe: molly
Topic: elementsFromPoint() and pointer-events:paint-order
<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
David: 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 elementsFromPoint()
Alan: For the second part (pointer-events: paint-order), I think it makes
sense to wait until we have implementations of elementsFromPoint()
Peter: Seems fair enough: opinions?
Peter: Resolved
no objection
RESOLVED: add elementsFromPoint() to cssom-view
ACTION: stearns to propose text for elementsFromPoint
<trackbot> Created ACTION-567
Selectors 4
-----------
Topic: Multiple Subject Indicators
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Jun/0240.html
Glazou: Describing issue
Glazou: Two possibilities - first if multiple, only last wins
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.htm
<dbaron> I don't like (b).
leaverou: 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
Glazou and Dbaron - syntactic sugar discussion
Peter: Is anyone implementing yet?
Lea: It's just syntactic sugar.
Glazou: put in selectors4
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
RESOLVED: multiple subject selectors allowed and all match, Selectors L4
Cross-Origin Style Sheets
-------------------------
<plinss> http://lists.w3.org/Archives/Public/www-style/2013Jun/0097.html
dbaron: I think people who are interested should go review the change.
Peter: Anyone else?
CSS3 Backgrounds
----------------
<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
<RRSAgent> http://www.w3.org/2013/06/19-css-minutes.html
Received on Wednesday, 3 July 2013 07:51:26 UTC