[CSSWG] Minutes Telecon 2013-02-28

Summary:

   - RESOLVED: Add Dael to CSSWG
   - RESOLVED: Accept jdaggett's proposal
               http://lists.w3.org/Archives/Public/www-style/2013Feb/0432.html
   - Discussed interaction of MQ and @page 'size', and similar situation with
     @viewport sizing.
   - RESOLVED: Accept Simon's fix to page names so they work on first page
               of document
   - Discussed painting order of page-margin boxes
   - RESOLVED: Add @page OM to css3-page, exact OM API TBD.
   - Discussed editorship of GCPM
   - Discussed fallback behavior with variables
   - RESOLVED: Publish WD of Variables with Simon Sapin's issues noted

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

Present:
   Glenn Adams
   Tab Atkins
   Rossen Atanassov
   David Baron
   Bert Bos
   John Daggett
   James Dovey (Rakuten)
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Daniel Glazman
   Rebecca Hauck
   Molly Holzschlag
   Dael Jackson
   Dean Jackson
   John Jansen
   Peter Linss
   Edward O'Connor
   Florian Rivoal
   Simon Sapin
   Dirk Schulze
   Alan Stearns
   Leif Arne Storset
   Nick Van den Bleeken
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2013/02/27-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Feb/0696.html
Scribe: fantasai

Administrative
--------------

   plinss: Extra topics?
   glazou: One related to css3-page / paged media in general
   glazou: Would like to add Simon as extra editor for GCPM
   <SimonSapin> not really css3-page if it's GCPM

   jdaggett: Would like to talk about last call push for CSS Variables
   plinss: Another thing wrt variables fantasai mentioned, too
   <glazou> agreed but falling in same basket SimonSapin

   plinss: First topic. Notice we have Dael Jackson on the call.
   plinss: She's agreed to be a dedicated scribe. Waiting for funding to
           go through.
   plinss asks if this sounds good to everyone
   * molly thinks poor dael has no idea what you signed up for
   Florian: Scribing requires not just fast typing, but also deep understanding
            of what we're talking about. Going to be a challenge.
   RESOLVED: Add Dael to CSSWG

Font Resource Handling
----------------------

   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2013Feb/0432.html
   jdaggett: Not sure we need to discuss... I proposed change to wording
             to one section
   jdaggett: No one really responded
   jdaggett: Propose taking this change
   plinss: Any objections?
   RESOLVED: Accept jdaggett's proposal above

CSS3 Page Issues
----------------

   SimonSapin: Have few small issues to resolve on
   <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013JanMar/0214.html

   http://lists.w3.org/Archives/Public/www-style/2013Feb/0096.html
   SimonSapin: Currently spec says that MQ resolve on default page size,
               do not consider any size property
   SimonSapin: Issue that maybe some size properties should be considered
   SimonSapin: Would be nice to have
   SimonSapin: But think current wording is consistent with MQ, resolve
               against default page size
   SimonSapin: Propose no change, just remove the issue
   SimonSapin: Any objections to that?

   Florian: No objection, but comment
   florian: Another spec not entirely dissimilar, device adaptation
   florian: MQ react to device adaptation
   florian: When you set a different viewport, MQ can react to the size of
            this viewport
   florian: This is different from @page
   florian: The resolution you propose is fine, and consistent with MQ
   florian: But I'm wondering if we're happy with this inconsistency
   florian: If you set @page size, they don't react; but if you set @viewport,
            they do
   SimonSapin: It's a good point, but what happens with @viewport inside
               @media with an MQ?
   florian: There's an algorithm in the spec
   florian: It doesn't have to be particularly elegant, it just has to
            break the cycle
   SimonSapin: Ok, I will look at this and come back next week
   florian: I'm uncomfortable with the two different directions

   fantasai: There are very good use cases for having MQ respond to page
             size or viewport size
   fantasai: paged-media says what it says because we had to resolve the
             conflict between setting a size and querying it

   http://lists.w3.org/Archives/Public/www-style/2013Feb/0097.html
   SimonSapin: There is some text in spec to ignore size declarations if
               qualified by MQ
   glazou: yes was resolved during a past ftf
   SimonSapin: My proposal was to remove that part of the spec *if* MQ is
               based on default size
   SimonSapin: Because it's not necessary in that case
   [ but need to resolve the previous issue first ]

   SimonSapin: Next issue - named pages
   http://lists.w3.org/Archives/Public/www-style/2013Feb/0640.html
   SimonSapin: Definition of named pages didn't allow first page to be named
   SimonSapin: So changed algorithm to work that way
   leif: Without this change, would it mean there would be a blank page
         at the beginning?
   SimonSapin: Only get a page break when value of page property changes
   SimonSapin: I think this change is more in spirit of the property.
               I think this was implemented behavior, never written down.
   plinss: So if you had an element saying it should be on page named "foo",
           and it's the first item, it would force a page break. Now it
           doesn't
   SimonSapin: Basically still has page names work even when there is no
               content before that element
   leif: ok, great
   * fantasai in favor of fixing this
   RESOLVED: Accept Simon's fix to page names so they work on first page
             of document

   <SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Feb/0652.html
   SimonSapin: z-index property is optional on page-margin boxes. Don't know
               why, so propose making it non-optional
   SimonSapin: If a UA supports it on elements, it must support it on
               page-margin boxes
   glazou: What would be the effect on page-margin boxes?
   SimonSapin: If they happen to overlap, you can choose which are on top
               with z-index
   dbaron: z-index only applies to positioned elements
   SimonSapin: Wording in spec that says z-index always applies
   dbaron: ok
   TabAtkins: Already applies automatically to flex items
   Rossen: and grid items
   glazou: When you flow an element into a margin box (via GCPM), does this
           affect that?
   SimonSapin: Wouldn't affect flow, only stacking
   glazou: Would like some time to look at this more closely

   florian: In theory what you're saying makes sense [...]
   * florian gave up speaking, muted, and types instead
   <florian> Simon makes sense, but I wonder if we could dig out why it was
             marked optional in the first place
+bradk
   fantasai: The reason it was marked optional was that, at the time, it
             was not implemented, and we were trying only to clean the spec
             up, not to add new features
   fantasai: We didn't see a reason to forbid z-index, so made it optional.

   plinss: Ok, let's come back next week. If someone wants to write tests
           and see if anyone implements it
   SimonSapin: WeasyPrint doesn't implement it, but think it would be good
               to have it, and would implement it if it's in the spec

   SimonSapin: Next issue
   <SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Feb/0653.html
   SimonSapin: The default order of page-margin boxes is not specified,
               because we didn't have a good answer
   SimonSapin: Suggest picking something arbitrary
   SimonSapin: e.g. start at top-left and go clockwise
   glazou: That would be a problem for rtl pages
   SimonSapin: z-index would allow changing the order
   SimonSapin: Also, only matters when there's overlap with the boxes,
               which we try not to do in the layout algorithm
   plinss: Do we have other cases where rotation depends on writing mode?
   glazou: My concern is rtl pages will forget to fix
   SimonSapin: Hopefully they will not overlap at all
   <SteveZ> Why not define starting at the start-before edge
   <SteveZ> Then go in the inline direction followed by the block direction
   * bradk likes the idea of re-imagining margin boxes and page box as grid.
   fantasai: I would like to know what Antenna House does, and if they
            thought about this problem. Because if they thought about it,
            they probably have a sensible answer

   SimonSapin: Could discuss particular order, but what about not leaving
               it undefined?
   Bert: It seems very rare to have overlapping, so probably need to use
         z-index anyway
   Bert: Don't think it's necessary to do anything complicated, just need
         some answer
   <florian> I am with Bert on this.
   glazou: Ok, I withdraw my objection, I agree with proposal. But relies
           on previous issue's resolution so give me a few days
   szilles: One advantage of undef is that ppl will always use z-index b/c
            doesn't know how it works
   plinss: Only if they test in multiple implementations
   szilles: Defining it fixed way, disadvantages some other languages
   <florian> Ask Antenna house, if they have an answer, use that, otherwise,
             define whatever
   SimonSapin: Still in favor of defining something.

   SimonSapin: One last issue, but will take a lot more time, so suggest
               deferring to after WD
   SimonSapin: wrt viewport units and ICB

   glazou: I have one issue
   glazou: My issue is simple, related to OM of page rule, as defined in
           CSS3 Page
   glazou: Paged Media L3 introduces new @rules inside @page rule
   glazou: OM currently unable to fix that. Would like to see at least a
           proposal or start of something about this new @page rule
   glazou: Noticed ConditionalRules introduces GroupingRule
   glazou: Might make sense to inherit from that.
   glazou: That would allow editors like mine to deal with declarations
           and @margin boxes inside @page rule. Otherwise not editable
           for me.
   TabAtkins: That's maybe not doable as written
   TabAtkins: GroupRule is used for things that contain declarations only
   TabAtkins: Might need a different interface, with slightly different API
   SimonSapin: Doesn't insertRule reject inappropriate things anyway?
   florian: declaration vs. rule

   SimonSapin: 2 ways to do this
   SimonSapin: Either have separate list of rules, same as at-media, and
               separately had style attribute, same as currently exist
   SimonSapin: But this does not preserve relative order of at-rules and
               declarations
   glazou: Preserving the order is IMO not an issue
   fantasai: I agree. The relative order here has no meaning.
   fantasai: Just need to preserve relative order of at-rules amongst
             themselves
   SimonSapin: Will this be the case in the future?
   TabAtkins: Think so
   TabAtkins: Actually...
   TabAtkins: I can see things in the future where relative order of
              declarations and at-rules might be important, e.g. mixins
              like SASS.
   SimonSapin: If we do want to preserve order, then it's much more
               complicated.
   glazou: It's a very complex discussion, suggest we don't go into that
           right now.
   -> mailing list

   SimonSapin: Does this belong in CSSOM or CSS3 Page?
   glazou asks Glenn
   <glenn> thinking
   <glenn> i'd say OM
   glazou: New specs like animations have their own OM
   <glenn> i'm open... if it is general that can  be used elsewhere, then
           probably OM
   glazou: CSSOM deals with everything else
   florian: Think CSSOM spec still has plenty of work to do for legacy thing.
   florian: For new things, should just define them in that spec
   florian: Force both editors and implementers deal with OM as they go
   <glenn> we  have effectively moved the CSSFontRule out to the font spec,
           so could move CSSPageRule out as well...
   glazou: Implementers will have to implement something anyway, so
   <stearns> +1 to OM in each module
   plinss: Keep CSSOM spec scoped to past behavior
   <glenn> yes to what peter said
   RESOLVED: Add @page OM to css3-page

GCPM Editorship
---------------

    * leif1 has to leave early, sorry. Just wanted to explicitly not object
      to SimonSapin editing css3-gcpm together with howcome, as was mentioned
      at the beginning of the call. (Though I have not consulted with howcome.)
   glazou: GCPM spec is bad shape, really old, some things in contradiction
           with charter
   glazou: Suggest new editor, Simon Sapin, to become 2nd editor on the spec
   jdaggett: howcome still an editor?
   glazou: Yes
   jdaggett: Is he ok with it?
   glazou: Not yet, we'll have to ask.
   glazou: But problem is changes we requested in the past multiple times
           were not made.
   jdaggett: I'd like to hear how howcome feels about that.
   glazou: We will anyway! We won't resolve w/o pinging him.
   plinss: Worth getting feedback from him before adopting formally

   florian: Seems to me different kinds of things in GCPM, some that
            should be there and go to REC there, and things that should
            go in another spec
   florian: From pov of migrating things to different specs, e.g. generate
            paged media based on overflow, this could be in dbaron's spec
   florian: Don't need extra editor to GCPM for that
   florian: just edit it elsewhere
   glazou: Sounds like action on chairs to get howcome's opinion
   SimonSapin: I think we'll need to have that discussion for each part
               of GCPM
   SimonSapin: Leave it there, or shift it elsewhere
   Florian: Agree with that.
   Florian: But GCPM really is a special spec, it's howcome's spec, hard
            to discuss without him.

Variables
---------

   <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013JanMar/0213.html
   <plinss> http://lists.w3.org/Archives/Public/www-style/2013Feb/0632.html
   SimonSapin: Issue is that this prevents usual mechanism of using cascade
               to find fallback values
   SimonSapin: It's pretty fundamental mechanism in CSS
   SimonSapin: Think we should preserve that
   SimonSapin: One way to solve is to keep around cascaded list
   SimonSapin: Keep around last declaration that's valid
   SimonSapin: After I raised this issue, Tab said it was rejected b/c
               implementations didn't want to remember multiple cascaded
               values
   TabAtkins: Implementations want to keep current optimization, where
              don't need to keep around all those values
   florian: Wondering if there's some kind of middle ground
   florian: Just remember two, one declaration variables, and one without
            variables.
   florian: Less memorizing. Doesn't give you full cascade
   florian: But maybe it's more confusing to have part cascade rather than
            full
   TabAtkins: Seen as weird to ignore declaration with variables that would
              have worked as a fallback

   TabAtkins: I do have some proposals to type-check variables early on,
              figure out whether invalid ahead of time
   TabAtkins: Not addressing in this level
   TabAtkins: Addresses a lot of fallback issues
   TabAtkins: Not as good as keeping full cascade, but fills in many holes
   SimonSapin: Would your proposal mean that validation of some declarations
               that use variables is done after the cascade, and some are
               done before?
   TabAtkins: Typing proposal makes variable itself to go invalid early.
              Fallback happens at variable level
   TabAtkins: rather than killing the property declaration
   TabAtkins: would then use fallback [...]?
   SimonSapin: Different fallback than what we already have
   florian: Keeping around cascade, as an implementer, much preferred Tab's
            proposal.
   TabAtkins: Variables are pretty memory-heavy, this would make it worse
   <bradk> You could keep the cascade list for each var-foo, and use
           earlier declarations of var-foo when later ones don't work.

   SimonSapin: I don't think it means keeping entire cascade around
   SimonSapin: Would only keep around up to first declaration that doesn't
               include variables
   SimonSapin: Most cases, this is only one declaration.
   SimonSapin: Cases with variables, usually pretty short anyway
   SimonSapin: Don't need to preserve anything before a declaration that
               does not use the var() function.
   SimonSapin: If this has been rejected before, I understand, but would
               like to hear from different impl what they think
   TabAtkins: I think this is not functionally different
   TabAtkins: Data structs still need to change, etc.

   glazou: Suppose you have multiple declarations for same properties in
           a block. Editor changes one to use variables, behavior then
           changes.
   TabAtkins: No, would match it
   <florian> I don't think Daniel's worry is warranted.
   glazou: If your variable is invalid
   TabAtkins: Simon's proposal gives same behavior as if the declaration
              was invalid
   glazou: I understand the rendering will be exactly the same, but it
           changes the way the declaration block is used, parsed, dealt
           with, inside the implementation. And that is not coherent.
   florian: I think Tab's changes it more.

   jdaggett: Could we talk about WD issue?
   jdaggett: As I look over spec, I realized we haven't published WD since
             April 2012. Would prefer if we publish WD and then publish LC
             after polishing
   jdaggett: Know we resolved LC, but think it's better to publish WD first
             and get more eyes on it. Some people don't follow
             day-to-day-changes in editor's draft
   jdaggett: And there are significant things that changed since last WD
   TabAtkins: I don't think anything significant has changed, but have no
              objection to publishing a WD
   jdaggett: Works for me
   <fantasai> sounds good to me
   <molly> fine by me
   <SimonSapin> +1 for a WD
   <SimonSapin> or any publication, really
   RESOLVED: Publish WD of Variables
   <molly> I agree it will get more eyes

   TabAtkins: I'm doing some corrections based on jdaggett's feedback, so
              will verify with him and then ask for publication
   fantasai: suggest marking Simon's issues in the spec, so that people
             notice and give feedback
   * fantasai notes there's more than one

Meeting closed.

Received on Friday, 1 March 2013 00:29:16 UTC