[CSSWG] Minutes Telecon 2013-06-19


   - 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

   - Please review css3-background issue on background-attachment: local

====== Full minutes below ======

   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


   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
   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>
   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

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
   <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