Re: [CSSWG] Minutes Telecon 2012-11-28

----- Original Message -----
From: "fantasai" <fantasai.lists@inkedblade.net>
To: www-style@w3.org
Sent: Thursday, November 29, 2012 4:59:13 AM
Subject: [CSSWG] Minutes Telecon 2012-11-28

Summary:
   - Discussed allowing background-clip and background-origin to be separated
     from each other in the 'background' shorthand
       http://lists.w3.org/Archives/Public/www-style/2012Nov/0374.html
   - Plan to take CSS3 Text / Text Decoration to LC next week unless there
     are reasons to hold back
   - Discussed FXTF telecon times and attendance
   - RESOLVED: Viewport units are relative to the first page's size only.
   - Discussed CR exit criteria and one person writing multiple implementations

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

Present:
   Glenn Adams
   Rossen Atanassov
   Tab Atkins (late)
   David Baron
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Dean Jackson?
   John Jansen
   Peter Linss
   Simon Sapin
   Dirk Schulze
   Alan Stearns
   Leif Arne Storset
   Steve Zilles

   Note: Zakim left several numbers unidentified.

<RRSAgent> logging to http://www.w3.org/2012/11/28-css-irc
Scribe: SteveZ

February F2F
------------

   Note from Molly which says changing the dates should not be a problem
   Please update the Wiki with your plans and everything else you need (e.g. spouse, special needs)
   <plinss> http://wiki.csswg.org/planning/tucson-2013

Backgrounds
-----------

   Topic: Unbinding background-clip from -origin in background shorthand
   <smfr> http://lists.w3.org/Archives/Public/www-style/2012Nov/0374.html
   <fantasai> 
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Ap%20{%20background%3A%20content-box%20red%20content-box%3B%20}%0A%3C%2Fstyle%3E%0A%3Cp%3Etest%20me
   <SimonSapin> makes sense to allow this
   Fantasai: Whether other values can be between Background and Clip
   Dirk: Firefox does not allow others do
   <krit> http://jsfiddle.net/WbWSF/
   <JohnJansen> IE10 is clipped with that test case
   Fantasai: reason we put them back to back was that it was simpler,
             but I do not have strong opinions;
   Fantasai: Given one implementation follows the spec we should not change it
   <oyvind> firefox doesn't allow two values at all, at least not in 17/stable
   <fantasai> oyvind: good point, that doesn't seem to work indeed
   krit: does Quirks mode affect this on IE? it doesn't on Safari/Chromium
   Fantasai: Quirks mode should not matter because this is not a legacy feature
   Fantasai: does anyone else have an opinion?
   It was noted that Firefox does not allow two values
   Krit: Webkit uses first for origin and second for clip
   A third value would make the specification invalid
   Fantasai: the spec is clear about the intended syntax
   dbaron: spec changed here
   fantasai: there used to be only one allowed value and then two were allowed
   DBaron: I prefer leaving it as it is because it is easier to implement
   krit: both Webkit and Opera correctly implement a single value, two values
         and ignoring the property if a third value is set
   PLinss: there are 3 implementations that agree, but do not implement the
           spec and one implementation that does implement the spec
   Sylvain: If we make a change that would put us back to LC
   Fantasai: We have to go to LC anyway to allow the inset and color keywords
             to be re-ordered
   ACTION krit to provide test case
   <trackbot> Created ACTION-524
   PLinss: we will revisit next week after test is posted

CSS3 Text etc.
--------------

   Fantasai: are there any more issues?
   PLinss: this is the LC for LC so we can decide to publish LC next week
   Fantasai: want to insure everyone, including JDaggett, can file any
             issues they have

FX TF meetings
--------------

   Dirk: There were FX TF meetings in the past with CSS and SVG folks;
         they stopped when CSS participation dropped
   Sylvain: What time will these meetings be?
   Dirk: there are attendees in Japan and Australia so we need to accommodate
         them; it was 10-11PM in Europe
   DBaron: Will these meeting be regular.
   <cabanier> cabanier: they used to be Monday afternoon PST
   Dirk: How about having a meeting only if there is an agenda
   DBaron: that is OK if the agenda comes at least 2 days prior to the meeting
   Dirk: I had sent agendas on the Wednesday prior to a following Monday meeting
   DBaron: I would join depending the the topics
   Dirk: the SF time was 1:30PM on Mondays
   <tantek> I would monitor it
   DBaron: I would prefer every other week so I can put a chron entry in my
           calendar
   Dirk: How about every even week?
   <dbaron> but every week is fine too
   DBaron: I can live with every week and cancelling as well
   <cabanier> It's unlikely that there will be many meetings in a row

viewport units (vw/vh/vmin/vmax) and varying page size
------------------------------------------------------

   http://www.w3.org/mid/50A04DD2.1030309@kozea.fr
   Simon: viewport units are based on the initial containing block which
          is only the first page, but units should vary across varying
          size pages
   Simon: the first page solution is easier to implement; but makes them
          useless for varying size pages
   PLinss: what happens with a entity is split across pages of different size
   Simon: If we choose that viewport units depend on the current page,
          then the width may vary across pages
   Rossen: This is the same problem as exists with percentages where
           fragments fit into different size containers
   Rossen: It is not that different to have the viewport relative values
           be computed differently for each fragment
   Rossen: IE does take advantage of the current initial containing block
           so I would be in favor of keeping that behavior.
   Simon: I agree that the viewport unit computation is like percentages
   Simon: If we go with using the current page then the computed value of
          every property would need to change to say "absolute value
          or a viewport unit"
+TabAtkins
   Rossen: this is not the case because all the values (today) are bound
           to an element so you only get one value per element
   Rossen: The API today is defined on an element that implies a single
           value per property. This does not allow returning the values
           for all the fragments an element might divide into
   Rossen: to solve this you would need to get the used values of the boxes
           (for the fragments)
   DBaron: If is not just about the API, it is about the concept of
           "computed value" and whether viewport units can be computed
           to a length within that concept
   Rossen: making the change to use the current page would make the value
           dependent on layout and would violate the "computed value" rule

   DBaron: We decided (not that long ago) that we wanted viewport values
           to compute to a length. I believe that we did this knowing it
           would not work with varying page sizes
   DBaron: changing this would cause current implementations to start over

   Fantasai: When you do not have varying page sizes you get the same
             results with either approach.
   fantasai: So I suggest we go with that, since it handles everything
             except this uncommon case.
   Fantasai: Maybe add a note to the spec to say that the interpretation
             may change in the future if varying page sizes become important
   Tab: We cannot change it in the future if we want viewport units to be
        computed values
   Simon: we need to change the note in Values and Units if we keep the
          first page rule
   Fantasai: there may be other places that need to be updated as well
   Fantasai: Alternatively, do we want to allow either interpretation being
             conformant right now?
   Rossen:

   Tab: a viewport unit that changes by the page will not be a 'definite size'
        (in the sizing spec) because it will depend on layout
   This means that the two choices are not "the same" for constant size pages
   Tab: making the unit conform to the varying page size makes viewport units
        be used value units rather than computed value units
   PLinss: I am reluctant to making a decision that would not allow the
           initial containing block to depend on the actual page size
   SteveZ: the viewport units are absolute so that a rotated table would use
           the vh to set its width
   Wrt layout, a rotated page is essentially one with a width/height opposite
   to the others
   RESOVLED: keep the specification of viewport units the same as now;
             that is that the first page is used
   <SimonSapin> action to update the v&u note?
   ACTION fantasai edit the spec
   <trackbot> Created ACTION-525

CR Exit Criteria
----------------

   https://lists.w3.org/Archives/Member/w3c-css-wg/2012OctDec/0219.html
   Tab: I do not know if anyone objected to the conclusion: namely, that
        if one person writes the code, even if in different products,
        that is considered to be one implementation
   <stearns> there's nothing restricting someone working on more than one
             implementation - there's just a requirement to go and find a
             third implementation in that case
   PLinss: I would not change our CR wording because because I want to
           allow time varying participation in different products
   DBaron and others: I do not think we need to further define "independent";
                      it's meaning in English is sufficient
   * fantasai agrees with dbaron and doesn't think this needs further
              discussion or change
   PLinss: if the tester writes his tests by reading the spec; that means
           a second pair of eyes came to the same interpretation as the
           implementer

Meeting closed.

Received on Tuesday, 4 December 2012 07:07:22 UTC