W3C home > Mailing lists > Public > www-style@w3.org > January 2013

[CSSWG] Minutes Telecon 2013-01-16

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 16 Jan 2013 18:28:21 -0800
Message-ID: <50F761C5.4000600@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:

   - Discussed F2F logistics; need more topics for agenda

   - Discussed interaction of viewport units and scrollbars, and avoiding
     relayout in 'overflow: auto' case.  Need use cases for deciding
     whether 'auto' should be laid out as 'hidden' or 'scroll'.

   - Discussed issues with Pointer Events spec
       http://lists.w3.org/Archives/Public/www-style/2013Jan/0182.html
     Specific concerns include:
       - Spec seems to confuse people as currently-written
       - The touch-action property might be overly-specific to touch interfaces
       - Discussed whether touch-action property is necessary.
       - Spec should show examples of how 'touch-action' is used in an
         all-declarative use case. (If it is only useful when JS is invoked,
         maybe its behavior should likewise be handled by JS, not by
         introducing a declarative property that's only useful when mixed
         with JS.)

   - Discussed CSS Masking, progress to LC. Issues raised include:
      - duplication of prose from CSS3 Backgrounds and Borders
      - interaction with 'overflow' property
      - clarifying behavior of 'no-clip' value

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

Present:

   David Baron
   Bert Bos
   Tantek «elik
   Elika Etemad
   Simon Fraserp
   Sylvain Galineau
   Daniel Glazman
   Brad Kemper
   Rebecca Hauck
   Molly Holzschlag
   Koji Ishii
   John Jansen
   Peter Linss
   Alexis Menard
   Edward O'Connor
   Anton Prowse
   Simon Sapin
   Dirk Schulze
   Alan Stearns

Agenda: http://lists.w3.org/Archives/Public/www-style/2013Jan/0193.html
Scribe: fantasai

[ See Appendix A for pre-meeting IRC comments ]

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

   plinss: Any other items? I saw dbaron's email. No?

   topic: F2F
   molly: Wanted to make sure we have everything in order for F2F, since
          I might not be available for next 2 meetings... available only
          via email
   molly: good shape w/ rooms
   molly: Only have a problem solving with koji, will take care of that

   molly: Meetings held at U of AZ on campus
   molly: They'll take care of catering
   molly: Only thing is, Wed night we have to leave the room by 5pm
   molly: Seems like it will be ok, is it a problem with anybody?

   molly: We'll be on a university campus, lots of resources
   molly: working on right now is social events
   molly: Daniel suggested a meetup
   molly: figure out which night is best, and who would like to do 5-7
          minute presentation?
   molly: related to CSS, CSS and community, design-oriented, W3C topic,
          whatever
   molly: Wondering if Tuesday is best night
   molly: Sunday make sure we have dinner for ppl arriving, from 8-10
   molly: I imagine a lot of ppl will be tired Monday night
   molly: so thinking Tuesday?
   molly: Let me know by end of day
   molly: Would like to know who's interested in topic and which night
          is better
   molly: That's it

   glazou asks about weather
   molly: We have had historic lows
   molly: 7-8 days under freezing at night
   molly: beautiful -- sun shining, sky clear -- but cold
   molly: Looks like it's warming up
   molly: don't need winter coats, but bring heavy sweater
   molly: will keep you posted
   <dbaron> http://en.wikipedia.org/wiki/Tucson#Climate

   <dbaron> FWIW, I find doing a meetup after 9 hours of meeting to be
            rather exhausting...
   [discussion of concerns wrt which day]
   <glazou> hey come on, he won't even change of TZ :-)
   molly: will aim for Tuesday then
   SimonSapin: I could give a presentation on CSS for printing
   plinss: call it Tues unless objection

   plinss: Please put topics on the F2F agenda!

Viewport Units
--------------

   <dbaron> https://lists.w3.org/Archives/Member/w3c-css-wg/2013JanMar/0051.html
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2012Dec/thread.html#msg47
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Jan/thread.html#msg200
   <dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19737
   dbaron: There are multiple implementations of viewport units, but major
           issue that prevents them from working right
   dbaron: Don't interact with scrollbars the way we want them to
   dbaron: Can't decide today, but next week.
   dbaron: We're pretty close to shipping, but can pull back if needed
   dbaron: Please look this thread over so we can decide next week

   dbaron: Tab and I are both thinking that if scrollbars on viewport are
           overflow: scroll/auto, you do subtract scrollbars. If hidden,
           then you don't
   dbaron: So subtract scrollbar even if in overflow: auto case where no
           scrollbars
   smfr: Trying to avoid relayout after trying the first time?
   SimonSapin: So you will have cases that 100vw won't match the size of
               the ICB?
   dbaron: This would cause that to be the case.
   dbaron: 100vw could be smaller than ICB by width of potential scrollbar
           in 'auto' case

   Rossen: One downside to this proposal, in default case where overflow
           is auto, always subtracting scrollbars
   Rossen: For layouts that are designed to fit within viewport, will have
           a gap
   Rossen: I see your reasoning for why you're subtracting the scrollbar
   Rossen: But I think we're shortcutting the implementation here.
   Rossen: Cases e.g. want to fill a canvas to screen
   Rossen: For us might not be a huge deal, since we're overlay scrollbars
           regardless for viewport
   Rossen: But I think we should think it through a bit more.

   dbaron: It's more than just circularity, but also layering problem.
   dbaron: Don't want computed values to be a function of layout
   dbaron: But do we make them so they behave like 'scroll' or so they
           behave like 'hidden' for 'auto' case.
   Rossen: Need to decide which case we're optimizing for
   Rossen: want to reinforce that what I've seen for most case is
           people building layouts that usually fit without scrolling
   Rossen: Maybe we can poll some public input

   dbaron: A bunch of cases where you could use viewport units, you
           could use 100%
   dbaron: Wondering what are solid use cases for viewport units where
           you can't use 100%
   dbaron: Not entirely obvious to me what those cases are

   Rossen: viewport unit to size pages
   Rossen: laid out side-by-side, or one-page view
   Rossen: always fit in the viewport
   Rossen: usually no scrollbar there

   Rossen: in our case we use overlay scrollbars for viewport
   Rossen: probably not make that much difference
   Rossen: want for us to not make this decision lightly without more
           input from users, and looking at real cases
   dbaron: If you have examples you can post, that would be great
   * fantasai suggests molly ask for use cases, examples

   dbaron: A use case I have is a slide deck in HTML
   dbaron: Most of the time they don't have scrollbars
   dbaron: But sometimes you wind up on a display that's different size
           than you designed for
   dbaron: When that happens, don't want to get cut off, want to scroll
           and have that work
   * fantasai thinks it's better to fill by default than gap by default
              for that case
   Rossen: Not sure if it's up to us to decide, or poll more opinions here

   fantasai: Could also revisit decision to make viewport units compute
             to an absolute length, treat more like percentages.
   dbaron: We'd pull our implementation then, b/c too expensive a feature
           to be worth implementing

   plinss: Come back to this next week.

<sylvaing> I'm answering Tab's question right now
<sylvaing> on www-style
<sylvaing> Let me see if I can call in

Pointer Events
--------------

   <plinss> http://lists.w3.org/Archives/Public/www-style/2013Jan/0182.html
   plinss: Pointer Events WG is asking for feedback
   plinss: Please review
   dbaron: Tab and I both sent email to their list
   <dbaron> Tab sent http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0017.html
            I sent http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0018.html

   smfr: Don't really understand why this is necessary since ? does these
         things based on whether nodes have touch event handlers
   smfr: So I'd like to see more justification for the touch-action property
    hober: i don't think we need touch-action when we already have preventDefault
   sylvaing: What kind of justification looking for?
   smfr: Think it's possible to get the behavior by registering touch events
   sylvaing: More productive for developers to do declaratively.

   smfr: Seems like use case here is ... default panning/zooming behavior
         of UA
   smfr: Authors want to do that when want to create their own handlers

   sylvaing: Idea is you want to be able to put your finger anywhere on
             the page, and have document follow your finger
   sylvaing: or pinch and have it zoom
   sylvaing: or in an overflow: scroll box, have panning/zooming only
             affect content inside that box
   sylvaing: Idea is for author to say that panning and zooming applies to
             a particular subtree
   sylvaing: Things inside it zoom out and pan together, but not things
             outside it
   sylvaing: Much easier to do that way than writing events

   dbaron: So what you said about how it works is not at all how I read
           the spec as saying
   dbaron: in that what it seems to say to me was
   dbaron: There's a set of things that can handle these events
   dbaron: Not entirely clear to me what those are, but sounded that if
           you had another one that could potentially do that inside your
           map, then the fact that you set 'none' value on an ancestor of
           the map, doesn't prevent the inner thing from handling the event
   sylvaing: So map has none, everything inside has auto,
   sylvaing: you have another none container in there?
   dbaron: For the map thing you were talking about, what do you put the
           none on?
   sylvaing: thing that contains the map
   dbaron: The parent of the thing that handles the touch stuff?
   dbaron: or element that handles the touch stuff?
   sylvaing: You guys referring to connection between property and ...
   sylvaing: Not sure I follow the problem
   dbaron: Maybe discuss this later, but spec should be clearer about what
           it's saying
   dbaron: though maybe feedback I sent was based on completely
           misunderstanding what the spec was saying
   sylvaing: ok, will try to check your email and see what it says

   smfr: For example, is it the UA doing panning/zooming inside the thing,
         or the page using pointer events?
   sylvaing: can do both, can intercept the events
   sylvaing: touch-action: none turns off UA behavior
   sylvaing: it's a way of saying elements that don't do special handling,
             event passes up; this says whether to stop at some intermediate
             ancestor
   smfr: Still sounds exactly what you can do with event handlers
   sylvaing: Can of course do with JS, but much easier to do with CSS
   sylvaing: It's syntactic sugar for a use case that's very common

   plinss: Making declarative rather than script makes sense
   plinss: Bothered a little bit if we're defining feature at too low a
           level, when concerned about a higher-level concept.
   plinss: If the issue is panning/zooming, should that be a touch event?
           Or work for other pointer inputs?
   * BradK would like a declarative approach that handled scroll wheel
           events too.
   smfr: Tendency of this spec to [...] pointer-events , which is different
         from pointer-events property, which is confusing
   plinss: My issue is, instead of touch-action, shouldn't this be
           panning-and-zooming?
   sylvaing: Yeah, naming is confusing, even values 'auto' / 'none'
             are confusing

   <smfr> There's a dependency from the CSS pointer-events spec on the
          DOM "pointer events" proposal
   <smfr> <http://www.w3.org/Submission/pointer-events/>

   plinss: Any feedback on this?
   plinss: Any group response?
   fantasai: I guess group response is, this is confusing? :)
   sylvaing: Interaction with actual events isn't clear
   sylvaing: And feedback wrt naming being inappropriate

   tantek: Example you mentioned with maps... that requires JS to make
           the maps work
   tantek: While I agree with having declarative shorthands
   tantek: But if you're going to have an example of how declarative-only
           feature is useful
   tantek: Should be an example that doesn't require JS for the rest of
           the example to work
   tantek: whatever the example is, should be declarative only, rather
           than depend on JS
   * fantasai agrees with tantek
   tantek: otherwise echo Simon's concern -- if you're doing things with
           JS anyway, have to handle details there anyway
   sylvaing: Could be picture, not a map
   tantek: Not saying declarative-only can't exist, just asking that they
           be used as examples
   * Bert agrees with tantek, too: the only reason to stop default actions
          is if there is some event handler that defines different actions.
          So the presence of that handler seems enough to stop the default
          actions.
   <sylvaing> Bert, no, you may want to stop a default action from propagating
              higher up without needed a custom handler. It's perfectly
              reasonable to want the content of an element to pan and zoom
              without affecting the document outside that container.

   fantasai: Happy to take 3 points here as feedback: naming is unclear,
             example should be declarative, spec is confusing
   plinss asks for volunteers

CSS Masking
-----------

   <smfr> https://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
   krit: I would like to go to LC, but first would like a review of it

   krit: also got email from dbaron today
   <dbaron> http://lists.w3.org/Archives/Public/public-fx/2013JanMar/0017.html
            was my post that dirk's responding to
   krit: he suggested that we share more text between CSS Backgrounds and
         CSS Masking
   krit: But feel that context of property defs is different from Backgrounds
   krit: Also worried about reading 2 specs instead of one
   dbaron: Flip side is that for ppl reading both specs, if it were shared,
          only read once
   dbaron: If not shared, have to read twice and figure out the differences.
   krit: but they are different
   dbaron: Different that applying to mask image instead of bg image, but
           would hope it's possible to encapsulate that in a small chunk
           of prose
   krit: If someone is interested in both specs, CSS Masking and CSS
          Background, then a lot of stuff is very familiar for him
   krit: But on the other hand, for someone who isn't interested in BG
   krit: needs to read two specs to understand one

   fantasai: One problem with duplicating the prose is that error-fixes
              have to go into both specs, which is a maintainability issue
   fantasai: Replicating prose also hides any differences; have to find
             the differences, then decide whether was editorial, was
              missing error fix, or was substantive intentional difference

   BradK: Any reason why we can't have a bg property that turns the current
          layer of the bg into a mask? Then don't have to recreate all
          other properties as mask properties
   krit: Intention was to specify behavior of webkit masking, combine with
         svg masking
   krit: Reuse bg property, then cannot use bg property itself
   fantasai: Really want those two to cascade independently.
   fantasai: Two completely different concepts, would want to set/reset
             independently
   BradK: ...
   BradK: Also in many cases might want to use a bg image as a mask;
          this way have to set properties twice
   krit: Comment to that... currently masking masks the whole element
   krit: was a suggestion to be able to mask different parts of a box
   krit: not the whole thing
   krit: compositing and blending has a new property for that
   krit: and it allows to explicitly say blend this element, or blend this
         part of the element
   krit: I think this is a good idea to add to filter effects / masking,
         but is a different topic
   krit: Don't agree that masking can be combined with background the
         right way
   BradK: That it can't or that not right solution
   krit: Both.
   BradK: Seems easier to use that way, already know how to use all the
         bg properties
   krit: Masking is not just masking the background, so why would we use
         background properties for it?
   BradK: Not saying that bg property would only mask bg, ..
   fantasai: wouldn't it be confusing for a background property to be
             masking the foreground?
   BradK: Already defining images associated with element
   fantasai: It's not an "images associated with the element" property,
             it's a background property.
   smfr: ... not just content in this element, but also descendants

   krit: This would actually revert a previous decision of the WG to use
         a mask property, and is beyond what I want to discuss with this
         spec at the moment
   krit: Would like to avoid reverting that decision
   plinss: Seems like a bad idea to overload bg props with something that
           isn't about backgrounds. Seems like a hack to me
   <tpod> Seems like a bad idea to collapse with bg props
   <tpod> Agreed with krit
   <tpod> We have other similar but different properties eg border and outline
   <tpod> Defaults are different, collapsing is different. Etc.
   <tpod> Yet they share a lot

   krit: Fine with referencing text from bg as much as possible, but still
         need property definitions in the masking spec
   dbaron: Agree for that, but also page of prose that looks like it's
           copied from bg spec, and unclear what the differences are
   krit: So, refernece text if not different, copy if diffeerent, OK.

   BradK: Define how it interacts with overflow?
   BradK: not quite clear on that
   ...
   krit: clip property from CSS2, copied over
   krit: Ok, so CSS Masking needs to define how it interacts with overflow

   plinss: Anything else on Masking?
   smfr: Do we have enough input from vendors other than WebKit to take
         this to LC?
   krit: New mask property just implemented by webkit
   krit: Would vendors be generally interested in following WebKit? Did
         not start an implementation yet
   dbaron: I haven't really looked at the spec closely
   dbaron: I can try and poke roc about it, better reveiwer for it
   fantasai: I would like a week to review
   dbaron: It's painful to review right now, due to copied prose from Background
   dbaron: And what I'm interested in is what's different
   smfr: Sounds like we want some editing before we say LC
   fantasai: So how about you make the edits so that the differences from
             BG become clear, then we all review it, and if it's good,
             send to LC

   BradK: Question about no-clip
   BradK: What if you have a repeating image? Does it repeat across the
          whole viewport?
   dbaron: This was removed from css3-bg
   krit: This is because by default, masks will clip everything to border box
   krit: no-clip avoids clipping to border box
   krit: Allows to show content outside border box
   krit: It could mask whole viewport; but content itself doesn't flood
         whole viewport
   BradK: Should specify that explicitly, because alternate interpretation
         is to clip to tiles that fit within border box
   krit: Could you send mail to public-fx? Thanks
   <dbaron> I think no-clip does make sense as a masking difference fro
            css3-background, though.

Meeting closed.

Appendix A
----------

<liam> ...
<liam> your mail about running headers, and about translating from docx etc
<glazou> of course, I will have to fight howcome on that but I'm not here
          for that, I really think PM and GCPM are faaaar too weak
<molly> I think there's an intriguing publishing model for print
                   there, but perhaps outside the focus we need in the group
<liam> we need to get to the point where it's being addressed (somewhere
        in W3C) fairly soon, for sure this year.
<glazou> molly: if browser vendors don't implement it, it is dead
<glazou> as are currently dead PM and GCPM
<liam> ebooks are changing people's expectation of the platform
<glazou> only batch processors implement it
<glazou> nobody cares
<molly> I think Opera put out one lab version last year or a
                   year ago
<glazou> liam: exactly !
<liam> people will go into a kiosk in an airport and say, "make me a print
        copy of this book while I check in to my flight".
<glazou> print-on-demand
<glazou> yes
<glazou> no more stocks in bookstores
<glazou> one demo book only
<glazou> want it ? we print it
<liam> I have seen this for google books
<glazou> with a micro-cameron press
<glazou> one book printed in 10 seconds
* liam has to go
<glazou> bye liam
<SimonSapin> glazou: page-margin boxes are weak, but I donít see existing
              implementations removing them any time soon even with a
              better altenative
<SimonSapin> compat issues with existing content are the same as on the
              web, even though at a smaller scale
<glazou> SimonSapin: existing implems are batch and I don't see browsers
          implement it any soon either...
<SimonSapin> glazou: so what?
<glazou> SimonSapin: epub readers and browsers are not batch !
<glazou> they need better than current PM/GCPM
<SimonSapin> glazou: should we remove a feature from the spec if only
              some implementations have it?
<glazou> yeah
<glazou> who said remove ?
<glazou> I said better
<glazou> better is L4
<SimonSapin> so better in addition to the current features?
...
<stearns> mmm - balanced text polyfill just posted: https://github.com/adobe-webplatform/balance-text
Received on Thursday, 17 January 2013 02:28:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:04 GMT