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

[CSSWG] Minutes Telecon 2013-07-10

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 10 Jul 2013 15:33:16 -0700
Message-ID: <51DDE12C.1000809@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - Discussed whether to require use of width-specific glyph variants in TCY
   - RESOLVED: Accepted dbaron's proposal for MQ white space erratum
   - RESOLVED: Whomever updates errata doc, must send update message to www-style.
   - RESOLVED: Define CORS stuff for shapes in Shapes
   - RESOLVED: Agreed to start drafting Shapes Level 2 as ED
   - RESOLVED: Grid auto-positioning uses sparse (sequential) packing
   - Discussed proposal for new mask shorthanding scheme
     and problems of back-compat with SVG mask references
   - Discussed background clipping area for background-attachment: local; general
     agreement to make it relative to scrollable area, will revisit next week.

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

   Glenn Adams
   Rossen Atanassov
   Shezan Baig
   David Baron
   John Daggett
   Justin Erenkrantz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Rebecca Hauck
   Koji Ishii
   Brad Kemper
   Philippe Le Hégaret
   Chris Palmer
   Anton Prowse
   Matt Rakow
   Florian Rivoal
   Dirk Schulze
   SImon Spin
   Alan Stearns
   Lea Verou
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2013/07/10-css-irc
ScribeNick: fantasai


   glazou: Justin suggested to host first 2014 F2F in NYC
   glazou: Right time to start looking for hosts. Not going to resolve now,
           but getting options would be cool.
   glazou: That said, extra items?

Writing Modes: TCY

   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Jul/0111.html
   jdaggett: Last week there was a resolution about the algorithm
   jdaggett: which left the decision to use width-specific variants up to the UA
   <jdaggett> http://lists.w3.org/Archives/Public/www-archive/2013Jul/0011.html
   <jdaggett> http://lists.w3.org/Archives/Public/www-archive/2013Jul/0014.html
   jdaggett: A UA could simply do scaling, or use width variants as it saw fit
   jdaggett: Posted some examples
   jdaggett: Example of 107
   jdaggett: showing scaling vs. variants
   jdaggett: This is imporant because font designer put this into the font
   jdaggett: UA shouldn't be synthesizing things
   jdaggett: UA should be required to use the variants
   jdaggett: Arguments about cases where other behaviors might be better
   jdaggett: Based purely on scaling, will produce different results based
             on width of glyphs
   jdaggett: See, e.g. second URL
   jdaggett: alphabetic text
   jdaggett: case 5, scaling only
   jdaggett: IA looks normal, but MM looks much lighter
   jdaggett: It will make a difference in readability
   jdaggett: Whereas case 4 has the right weight
   jdaggett: This is already what implementations are doing
   jdaggett: Would like this to be the required behavior, so we can actually
             test it
   fantasai: We can test things that aren't required.
   fantasai: We do this in other places

   <stearns> given http://lists.w3.org/Archives/Public/www-style/2013Jul/0179.html,
             I'm assuming we should require width variant glyphs when all
             the glyphs have variants, but allow UAs to do what they want
             when the TCY run has glyphs with no variants available
   florian: Case of #12, some glyphs have variant and some don't
   florian: Think we should say this case is undefined
   florian: Do we all agree on this?
   jdaggett: I'm fine to say, use width variants if all characters have width
   rossen: I agree with jdaggett. When we implemented text-combine-horizontal,
           we assumed that if the font provides glyphs, then we should use those
   rossen: And not create a crappy-looking solution just because we can do
           it cheaper
   rossen: Have a question, when we are going to require that we use the
           font variants
   rossen: Are we talking about digits, or regardless of which
           text-combine-horizontal we're using?
   rossen: e.g. case of text-combine: all, only 3 characters
   rossen: would we also consider those?
   fantasai: Considering any case

   <fantasai> http://dev.w3.org/csswg/css-writing-modes/#text-combine-horizontal
   <fantasai> Current text, fwiw (based on last week's resolution):
     The UA must ensure that the combined advance width of the composition
     fits within 1em by compressing the combined text if necessary. (This
     does not necessarily mean that the glyphs will fit within 1em, as some
     glyphs are designed to draw outside their geometric boundaries.) The
     UA may use any means to do so, including substituting half-width,
     third-width, and/or quarter-width glyphs provided by the font or using
     other font features designed to compress text horizontally.

   florian: jdaggett made case that if font designer made glyphs available,
            should use them
   florian: Question, are these glyphs designed only for TCY?
   florian: There was also the case that these glyphs force monospace design
   florian: But in some cases proportional width might be better
   florian: Here we are not explicitly asking for half-width, you're asking
            for TCY
   florian: Easy to see these two things are related, but not necessarily
            1-1 mapping
   [some amount of argument over Florian's question]
   florian: If these glyphs are only designed for TCY, better case that
            they are the best thing to use
   <SteveZ> For example I have, in the past, seen IBM in tate-chu-yoko
   jdaggett: twid and qwid, definitely only for TCY. half-width, I don't know
   <sgalineau> even assuming the 1/n glyphs were not designed with TCY in
               mind the UA has no way to tell. Only the author can.

   <stearns> can we resolve on using the variants when all the glyphs in
             the TCY run have variants available?

   jdaggett: If you scale based on width of 2-char proportional span, this
             will result in variations in scaling factor
   jdaggett: which gives poor readability
   koji: I think you misunderstood what fantasai said
   koji: Both she and I agree that width variants is better than scaling
   koji: But sometimes you don't have to scale at all, and that's even
         better than half-width variants.
   jdaggett: That seems like a case where difference between half-width
             variants and proportional glyphs will be very minor
   jdaggett: Very minor
   koji: Not very minor
   glazou: We're far beyond 10min limit

   jdaggett: I think we need more examples from ppl arguing against this
   <fantasai> I suggest A' as an example where hwid would not be good

   <SteveZ> A different view: the problem is the requirement that the result
            fit into 1 EM; the Adobe folks (with Japanese typography experience)
            that I consulted said the tate-chu-yoko should be as wide as is
            needed and not affect line-spacing

Media Queries

   Topic: White space in media queries
   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Jul/0130.html
   glazou: Saw answer from dbaron on ML
   florian: What we resolved awhile ago was that there are differences in
            the WS handling of MQ and @supports
   florian: @supports requires space between ')', 'and'
   florian: We decided to make this the same
   florian: Missed on some subtleties
   florian: One is that, unlike @supports, not everything is between parens
   florian: e.g. @media screen and (min-width: ...)
   florian: Currently we don't require a space between 'screen' and 'and'.
            You could put a comment instead of a space to separate them.
   florian: To make things clean, suggest just requiring space there.
   florian: Also @supports not ... requires space after not, MQ doesn't...
   florian: Proposal is to harmonize all that
   florian: by requiring spaces

   florian: I proposed a new grammar; dbaron proposed a better grammar
   florian: Suggest we go with what he said
   <SimonSapin> +1, ship it
   fantasai: I'm in favor
   <bkardell> +1
   glazou: me too
   <dbaron> +1
   glazou: No objection?
   RESOLVED: Accepted

Reviewing Errata

   dbaron: Another comment --
   dbaron: I think errata need more review
   <SimonSapin> +1 dbaron
   dbaron: I think there have been errata posted to more than one of our
           specs that don't match our resolutions.
   dbaron: They should be announced to www-style for review by the person
           updating the errata document.
   plh: I think would be easy for whoever updated errata doc to do that.
   RESOLVED: Whomever updates errata doc, must send update message to www-style.


   jdaggett: Quick question...
   jdaggett: There was a request to publish LC of Fonts. Is anyone going to
             do it?
   jdaggett: There was a request to publish... and no response from anybody
   plh: I'll check; currently transitioning webmasters
   plh: I'll double-check on that.


   topic: Cross-origin style sheets
   glazou: Anyone able to handle that? No one from Opera?

   topic: Shapes
   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Jun/0096.html
   stearns: Where to define how to allow images from other origins in a
            stable way
   stearns: My understanding is that we need to define a [..] mechanism
            where you pass a CORS flag and get a response that [..]
   stearns: I can define this in Shapes, specifically
   stearns: Or we can put it in CSS images, for the image type in general
   stearns: I think that's really the only question -- where should it be
   rossen: I don't care that this is part of Shapes
   stearns: Any other opinions?
   stearns: I'll put it into Shapes
   fantasai: If we need to factor it out later, we can do that later
   RESOLVED: Define CORS stuff for shapes in Shapes

   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Jun/0514.html
   stearns: People in SVG want to point to some future CSS work for what
            they want to do
   stearns: particularly wrt shape-inside
   stearns: though not on anyone's plate to do that right atm
   stearns: Proposed to take what's on the wiki page, make a Shapes Level
            2 draft
   glazou: No problem with that
   glazou: Most of what you added was already in the L1 drafts. Not as if
           we never agreed to work on that. So in favor
   glazou: other opinions?
   * fantasai no objection
   RESOLVED: Shapes L2 ED agreed

Grid Layout

   topic: Grid Auto-placement Algorithm
   <stearns> http://dev.w3.org/csswg/css-grid/#auto-placement-algo
   <glazou> yes, sorry, bad url
   Issue 17
     This algorithm creates a "sparse" packing, where holes left behind are
     never filled in. This is more efficient and predictable (items never
     move to a position far above/before their preceding sibling), but the
     gaps are unwanted by authors in some situations. We should have a
     switch to allow for dense packing. (WebKit's current implementation
     does dense packing.)
   fantasai: Two ways to do auto-placement
   fantasai: Sparse packing... you start in the 1, 1 slot
   fantasai: and then place the next item that fits
   fantasai: move to the next empty slot, and put the next item
   fantasai: If something doesn't fit you keep moving until you find an
             empty slot that's big enough

Scribe: dbaron
   Rossen: how do you define "fit"?
   fantasai: the span -- the number of cells
   fantasai: Suppose you have 3 columns, and an item that is a 1x1, and
             then you place another item that's 1x1.  Then if you have an
             item that's 2x2, you move to the next row and leave an empty
             slot in the first row.
   fantasai: (etc.)
   fantasai: so you leave behind a bunch of holes
   Rossen: so it doesn't fit based on the number of columns, not based on
           sizing properties?
   fantasai: right

   fantasai: That's the sparse packing option.  Advantage of it is that
             things are in the order they appear.
   fantasai: Other option is dense packing, which says you go back
   fantasai: If you have a 1x1 empty slot on the first row that you skipped
             because there's a 2x2 item, you go back and fill that hole.
   fantasai: Advantage is no holes, disadvantage is that things get out
             of order.
   fantasai: When we discussed at Microsoft, thought it made more sense
             to do sparse packing, at least for this level.
   fantasai: Sparse packing is simpler, and don't get unexpected out-of-order.
   fantasai: We have the option of adding a way to turn on dense packing in a later level.
   <bkardell> I like the idea of dense packing as an option later
   fantasai: I think this is the best thing to do; don't get unexpected
             results, and dense packing would be an opt-in (ok to go out
             of order).
   <stearns> +1 to default to sparse, with an optional switch for dense

   bradk: would that be based on the 'order' property?
   bradk: ???
   fantasai: Yeah, the order used is the order-modified document order.
   ?: what's default of 'order'?
   fantasai: 0
   * fantasai has a proposal in her inbox from florian to call 'order'
              'visual-order' and wishes we'd gone with that, since it
              makes it clear it doesn't affect speech/DOM :/
   bradk: order is for the ???, not for the ??? itself, right?
   fantasai: couldn't hear
   bradk: was just saying that if ... then it would be sparsely packed,
         otherwise densely packed
   stearns: <missed>
   bradk: but you could have order be something that overrides the dense packing
   <bkardell> grid-visual-order?
   stearns: I don't think this should be related.
   stearns: order property just changes the dom order and that's the only
            effect it should have on the packing algorithm
   Rossen: Think of order as a pre-order .... reordering the elements.
           Before layout.
   bradk: could imply the author's intent to keep them in that order
   Rossen: they are being kept in that order
   bradk: ok, then.  I don't feel strongly.
   Rossen: <inaudible about not being able to ... examples>

   Rossen: From impl pov ...; but definitely easier to explain.
   Rossen: ... float layout... position float, if not enough space, push
           below until find space.  You never backtrack.
   Rossen: So sparse ordering or auto ordering will ... that, dense will
           be fancier in terms of implementation but not sure it's more
           intuitive for users.
   * stearns agrees that dense packing is like a more complicated float stacking

   Rossen: so should we go with sparse?
   bradk: I don't feel strongly.
   glazou: I think we should.
   RESOLVED: sparse packing for grid auto position

mask shorthand

   <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013AprJun/0287.html
   <krit> http://dev.w3.org/fxtf/masking/
   <krit> http://dev.w3.org/fxtf/masking/#box-image-masks
   krit: shorthand is bad
   krit: request from fantasai about making one mask property that turns
         off all masking
   krit: fantasai wanted mask to reset mask-box-image etc.
Scribe: fantasai
   krit: fantasai requested that 'mask' also reset 'mask-image' and related

   krit: Request led to new design for mask properties
   krit: where 'mask' would be overall shorthand for all masking properties
   krit: here's a link for how it could look like
   <krit> http://lists.w3.org/Archives/Public/www-style/2013Jun/0645.html
   krit: we would have mask-layers, which would be like 'background' shorthand
   krit: and we would have mask-element, which does svg references
   krit: and then mask-box, like box-image
   krit: seem to have agreement on overall structure

   krit: question is, what is the shorthand able to set?
   krit: shorthand similar to 'border' shorthand -- resets all border
         properties including border-image, but not able to set border-image
   krit: My proposal is to have 'mask' only set mask-element
   krit: It already does that
   krit: and it's hard to distinguish URLs for different things, so hard
         to add in anything other than mask-element reference

   smfr: So, you're saying if you use 'mask' shorthand, can't set both
         mask-box and mask-layers?
   smfr: So you have mutually-exclusive options in a shorthand... which
         is confusing to me
   florian: It does happen, not that rarely, that you can do basic things
            in shorthand and other things need to go to longhand
   krit: fantasai would like to also allow mask-box / mask-layers into shorthand
   krit: but this leads to parsing problems, because url() is ambiguous
   smfr: Sounds like it would be a very confusing shorthand
   krit: Problem is really that these all use url() function
   krit: Need to distinguish which property you want to assign the url()
         to at parse time

   krit: One idea was to check for fragID, assume it's an element
   krit: But request that we don't do that
   florian: No, that doesn't seem pretty
   smfr: So saying mask-layers is not part of shorthand at all?
   smfr: But can reset the masks with the shorthand?
   florian: shorthand can only set 'none'
   smfr: So confusing
   smfr: properties interact in non-symmetrical ways
   <SimonSapin> 'border' also resets 'border-image' but can not set it
   krit: mask-layers is already a shorthand
   smfr: I think this adds too much confusion for something that won't be
         used very often

   krit: Even without this, still kindof hacky
   krit: because of 'mask' setting SVG masks right now
   florian: This doesn't bother me much
   glazou: Opinions here? smfr thinks undesirable?
   smfr: Think it's too much complexity to get one part of behavior
   florian: I'm ok with it
   krit: If we don't do this, we still need a way to distinguish mask element
         and mask layers
   bkardell: Is this just about having top-level shorthand support
             none | <mask-element> ?

   smfr: mask-element is the svg-style one
   smfr: not represented in WebKit prefixed version
   smfr: Which are possibly used more often than SVG one
   krit: Might be right
   glazou: What should we do now?

   krit: 'mask: <mask-element> | none' is part of SVG REC
   bkardell: if I understand correctly, question is, either there is no
             mask shorthand directly
   bkardell: Or, is it this limitation of mask-element || none?
   krit: We have this mask property already, which points to SVG. So either
         way, we need a way to handle this back-compat situation
   bkardell: I like ability to say 'none' at the shorthand level

   florian: I really don't like parse-the-url thing
   florian: Everything else so far, I'm comfortable with, but that I'd like
            to avoid
   * fantasai too

   krit: I don't think smfr's proposal is possible.
   smfr: Just have 3 separate properties
   <bkardell> not possible even if it can only do none?
   krit: mask-element will have to be called just 'mask', then
   krit: because we already have this property in spec + implementations
   [basically, 'mask: none | <uri>' has to work somehow ]

   fantasai: I guess one thing to think about is, is there anything we can
             do to the syntax in the shorthand that would let us distinguish
             the longhands in it?

CSS3 Backgrounds

   Topic: painting area & background-attachment: local
   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Jun/0276.html
   SimonSapin: Decided recently, positioning area of
               background-attachment: local is the scrolling area
   SimonSapin: Think it should be the same for the clipping area
   SimonSapin: If we consider the background is inside the scroll box
   SimonSapin: It should also keep the same as the content, that is the
               padding box
   SimonSapin: So intersection of rectangle based on background property
               and clipping property
   glazou: Opinions?

   smfr: What is the visible difference?
   SimonSapin: Mostly when you have bg-clip: content-box; and some padding
   SimonSapin: You have some area that has no background at the top, but
               when you scroll that area disappears
   SimonSapin: but if you consider that the clipping area is not scrolling,
               then you always have this padding not scrolling as well
   smfr: I think I understand, but would love testcases / diagrams

   fantasai: I totally agree with this, it is obviously the right thing to do
   <glazou> +1
   <bkardell> looks good to me

   smfr: seems you'd use different clipping for different bg layers based
         on whether local or not
   smfr: Would make implementations a little more complex
   SimonSapin: Possibly
   SimonSapin: Currently working on patch for that in Gecko. Not a problem
               for us, though might depend on architecture

   glazou: Anyone objecting?
   <bradk> Should it also depend on presence of scrollbars?
   smfr: I would like diagrams
   glazou: OK, revisit next week

   <SimonSapin> smfr, the diagrams should be the same as for the positioning
   <SimonSapin> but I could make more with padding and border-radius, if that
   <SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013May/0542.html

   <smfr> I'm a bit worried about implementation complexity

glazou: And we have 1 minute on the call... anything else for 1 minute?
Meeting closed.
Received on Wednesday, 10 July 2013 22:33:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:12 UTC