15:11:09 <RRSAgent> RRSAgent has joined #css
15:11:09 <RRSAgent> logging to http://www.w3.org/2013/07/10-css-irc
15:11:14 <glazou> Zakim, this will be Style
15:11:14 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 49 minutes
15:11:19 <glazou> RRSAgent, make logs public
15:14:17 <dbaron> dbaron has joined #css
15:25:26 <dbaron> dbaron has joined #css
15:50:22 <lmclister> lmclister has joined #css
15:51:01 <shezbaig_wk> shezbaig_wk has joined #css
15:53:30 <MaRakow> MaRakow has joined #CSS
15:54:49 <jerenkrantz_> jerenkrantz_ has joined #css
15:56:53 <florian> florian has joined #css
15:57:21 <Zakim> Style_CSS FP()12:00PM has now started
15:57:28 <Zakim> +??P19
15:57:34 <glazou> Zakim, ??P19 is me
15:57:34 <Zakim> +glazou; got it
15:58:29 <Zakim> +jerenkrantz
15:58:32 <bradk> bradk has joined #css
15:58:42 <jdaggett> jdaggett has joined #css
15:58:44 <Zakim> +plinss
15:59:28 <Zakim> +[IPcaller]
15:59:36 <antonp> antonp has joined #css
15:59:40 <jdaggett> zakim, ipcaller is me
15:59:40 <Zakim> +jdaggett; got it
15:59:41 <smfr> smfr has joined #css
15:59:49 <Zakim> +Stearns
16:00:08 <tantek> tantek has joined #css
16:00:25 <Zakim> +fantasai
16:00:31 <Zakim> +Plh
16:00:32 <Zakim> -fantasai
16:00:32 <Zakim> + +1.206.675.aaaa
16:00:44 <rhauck> rhauck has joined #css
16:00:50 <Zakim> +??P48
16:00:57 <Zakim> +fantasai
16:01:01 <glenn> zakim, ??p48 is me
16:01:01 <Zakim> +glenn; got it
16:01:13 <Zakim> +??P50
16:01:24 <SimonSapin> Zakim, ??P50 is me
16:01:25 <Zakim> +SimonSapin; got it
16:01:25 <Zakim> +smfr
16:01:27 <Zakim> +jerenkrantz.a
16:01:42 <shezbaig_wk> zakim, jerenkrantz.a is me
16:01:43 <Zakim> +shezbaig_wk; got it
16:02:11 <Zakim> + +1.415.615.aabb
16:02:13 <Zakim> +antonp
16:02:16 <Zakim> +??P61
16:02:17 <Zakim> +SteveZ
16:02:20 <Zakim> +??P64
16:02:26 <rhauck> zakim, aabb is me
16:02:26 <Zakim> +rhauck; got it
16:02:29 <Zakim> +dbaron
16:02:39 <krit> krit has joined #css
16:02:43 <SteveZ> SteveZ has joined #css
16:02:44 <sgalineau> Zakim, aaaa is me
16:02:44 <Zakim> +sgalineau; got it
16:02:57 <Zakim> -??P64
16:03:08 <glazou> http://www.w3.org/TR/its20/#its-param
16:03:28 <Zakim> + +1.415.832.aacc
16:03:35 <Zakim> +[IPcaller]
16:03:37 <florian> Zakim, [IPcaller] has me
16:03:37 <Zakim> +florian; got it
16:03:44 <krit> Zakim, aacc is me
16:03:44 <Zakim> +krit; got it
16:04:02 <Zakim> +BradK
16:04:43 <fantasai> ScribeNick: fantasai
16:05:13 <fantasai> glazou: Justin suggested to host first 2014 F2F in NYC
16:05:23 <koji> koji has joined #css
16:05:27 <fantasai> glazou: Right time to start looking for hosts. Not going to resolve now, but getting options would be cool.
16:05:34 <fantasai> glazou: That said, extra items?
16:05:59 <fantasai> Topic: text-combine-horizontal
16:06:01 <glazou> http://lists.w3.org/Archives/Public/www-style/2013Jul/0111.html
16:06:05 <Zakim> +[Microsoft]
16:06:08 <fantasai> jdaggett: Last week there was a resolution about the algorithm
16:06:19 <Zakim> +[IPcaller.a]
16:06:22 <fantasai> jdaggett: which left the decision to use width-specific variants up to the UA
16:06:23 <MaRakow> Zakim, [Microsoft] is me
16:06:23 <Zakim> +MaRakow; got it
16:06:29 <koji> zakim, [ipcaller.a] is me
16:06:29 <Zakim> +koji; got it
16:06:31 <jdaggett> http://lists.w3.org/Archives/Public/www-archive/2013Jul/0011.html
16:06:31 <jdaggett> http://lists.w3.org/Archives/Public/www-archive/2013Jul/0014.html
16:06:37 <fantasai> jdaggett: A UA could simply do scaling, or use width variants as it saw fit
16:06:41 <fantasai> jdaggett: Posted some examples
16:07:16 <Zakim> +Lea
16:07:19 <fantasai> jdaggett: Example of 107
16:07:24 <rhauck1> rhauck1 has joined #css
16:07:27 <fantasai> jdaggett: showing scaling vs. variants
16:07:45 <fantasai> jdaggett: This is imporant because font designer put this into the font
16:07:49 <fantasai> jdaggett: UA shouldn't be synthesizing things
16:07:57 <fantasai> jdaggett: UA should be required to use the variants
16:08:12 <fantasai> jdaggett: Arguments about cases where other behaviors might be better
16:08:29 <fantasai> jdaggett: Based purely on scaling, will produce different results based on width of glyphs
16:08:34 <fantasai> jdaggett: See, e.g. second URL
16:08:43 <fantasai> jdaggett: alphabetic text
16:08:47 <fantasai> jdaggett: case 5, scaling only
16:08:58 <fantasai> jdaggett: IA looks normal, but MM looks much lighter
16:09:04 <fantasai> jdaggett: It will make a difference in readability
16:09:18 <fantasai> jdaggett: Whereas case 4 has the right weight
16:09:22 <fantasai> jdaggett: This is already what implementations are doing
16:09:30 <fantasai> jdaggett: Would like this to be the required behavior, so we can actually test it
16:09:51 <Zakim> -SimonSapin
16:09:52 <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
16:10:07 <fantasai> fantasai: We can test things that aren't required.
16:10:17 <fantasai> fantasai: We do this in other places
16:10:30 <fantasai> florian: Case of #12, some glyphs have variant and some don't
16:10:37 <fantasai> florian: Think we should say this case is undefined
16:10:41 <Zakim> +??P97
16:10:42 <fantasai> florian: Do we all agree on this?
16:10:49 <SimonSapin> Zakim, ??P97 is me
16:10:49 <Zakim> +SimonSapin; got it
16:11:00 <fantasai> jdaggett: I'm fine to say, use width variants if all characters have width variants
16:11:27 <fantasai> rossen: I agree with jdaggett. When we implemented text-combine-horizontal, we assumed that if the font provides glyphs, then we should use those
16:11:39 <fantasai> rossen: And not create a crappy-looking solution just because we can do it cheaper
16:11:49 <fantasai> rossen: Have a question, when we are going to require that we use the font variants
16:12:00 <fantasai> rossen: Are we talking about digits, or regardless of which text-combine-horizontal we're using?
16:12:11 <fantasai> rossen: e.g. case of text-combine: all, only 3 characters
16:12:20 <fantasai> rossen: would we also consider those?
16:12:43 <fantasai> fantasai: Considering any case
16:13:00 <fantasai> florian: jdaggett made case that if font designer made glyphs available, should use them
16:13:05 <Zakim> + +1.520.280.aadd
16:13:12 <fantasai> florian: Question, are these glyphs designed only for TCY?
16:13:23 <fantasai> florian: There was also the case that these glyphs force monospace design
16:13:35 <fantasai> florian: But in some cases proportional width might be better
16:13:50 <bkardell> bkardell has joined #css
16:13:58 <fantasai> florian: Here we are not explicitly asking for half-width, you're asking for TCY
16:14:07 <fantasai> florian: Easy to see these two things are related, but not necessarily 1-1 mappin
16:14:09 <fantasai> g
16:14:40 <fantasai> http://dev.w3.org/csswg/css-writing-modes/#text-combine-horizontal
16:14:43 <fantasai> Current text, btw
16:14:56 <fantasai> 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 tex[CUT]
16:15:04 <glazou> s/look/lock
16:15:15 <fantasai> [some amount of argument over the question]
16:16:07 <fantasai> florian: If these glyphs are only designed for TCY, better case that they are the best thing to use
16:16:09 <SteveZ> For example I have, in the past, seen IBM in tate-chu-yoko
16:16:19 <fantasai> jdaggett: twid and qwid, definitely only for TCY. half-width, I don't know
16:16:35 <JohnJansen_> JohnJansen_ has joined #CSS
16:16:37 <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.
16:16:47 <fantasai> jdaggett: If you scale based on width of 2-char proportional span, this will result in variations in scaling factor
16:16:54 <fantasai> jdaggett: which gives poor readability
16:17:18 <fantasai> koji: I think you misunderstood what fantasai said
16:17:27 <stearns> can we resolve on using the variants when all the glyphs in the TCY run have variants available?
16:17:29 <fantasai> koji: Both she and I agree that width variants is better than scaling
16:17:38 <fantasai> koji: But sometimes you don't have to scale at all, and that's even better than half-width variants.
16:17:53 <fantasai> jdaggett: That seems like a case where difference between half-width variants and proportional glyphs will be very minor
16:17:56 <fantasai> jdaggett: Very minor
16:17:59 <fantasai> koji: Not very minor
16:18:16 <fantasai> glazou: We're far beyond 10min limit
16:18:31 <fantasai> jdaggett: I think we need more examples from ppl arguing against this
16:18:45 <fantasai> I suggest A' as an example where hwid would not be good
16:18:55 <fantasai> Topic: White space in MQ
16:18:58 <glazou> http://lists.w3.org/Archives/Public/www-style/2013Jul/0130.html
16:19:05 <fantasai> glazou: Saw answer from dbaron on ML
16:19:20 <fantasai> florian: What we resolved awhile ago was that there are differences in the WS handling of MQ and @supports
16:19:42 <fantasai> florian: @suports requires space between ')', 'and'
16:19:48 <fantasai> florian: We decided to make this the same
16:19:53 <fantasai> florian: Missed on some subtleties
16:20:03 <fantasai> florian: One is that, unlike @supports, not everything is between parens
16:20:06 <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
16:20:11 <fantasai> florian: e.g. @media screen and (min-width: ...)
16:20:25 <fantasai> florian: Currently we don't require a space between 'screen' and 'and' -- you could put a comment
16:20:33 <fantasai> florian: To make things clean, suggest just requiring space there.
16:20:49 <fantasai> florian: Also @supports not ... requires space after not, MQ doesn't...
16:20:57 <fantasai> florian: Proposal is to harmonize all that
16:21:00 <fantasai> florian: by requiring spaces
16:21:09 <fantasai> florian: I proposed a new grammar; dbaron proposed a better grammar
16:21:13 <fantasai> florian: Suggest we go with what he said
16:21:13 <SimonSapin> +1, ship it
16:21:18 <fantasai> fantasai: I'm in favor
16:21:19 <bkardell> +1
16:21:20 <fantasai> glazou: me too
16:21:23 <dbaron> +1
16:21:24 <fantasai> glazou: No objection?
16:21:27 <fantasai> RESOLVED: Accepted
16:21:38 <fantasai> dbaron: Another comment --
16:21:42 <fantasai> dbaron: I think errata need more review
16:21:49 <SimonSapin> +1 dbaron
16:21:59 <fantasai> dbaron: I think there have been errata posted to more than one of our specs that don't match our resolutions.
16:22:14 <fantasai> dbaron: They should be announced to www-style for review by the person updating the errata document.
16:22:25 <fantasai> plh: I think would be easy for whoever updated errata doc to do that.
16:22:54 <fantasai> RESOLVED: Whoever updates errata doc, must send update message to www-style.
16:23:04 <fantasai> jdaggett: Quick question...
16:23:19 <fantasai> jdaggett: There was a request to publish LC of Fonts. Is anyone going to do it?
16:23:34 <fantasai> jdaggett: There was a request to publish... and no response from anybody
16:23:48 <fantasai> plh: I'll check; currently transitioning webmasters
16:23:54 <fantasai> plh: I'll double-checkon that.
16:24:06 <fantasai> topic: Cross-origin style sheets
16:24:24 <fantasai> glazou: Anyone able to handle that? No one from Opera?
16:24:44 <fantasai> topic: Shapes
16:24:45 <glazou> http://lists.w3.org/Archives/Public/www-style/2013Jun/0096.html
16:25:16 <fantasai> stearns: Where to define how to allow images from other origins in a stable way
16:25:35 <fantasai> stearns: My understanding is that we need to define a [..] mechanism where you pass a CORS flag and get a response that [..]
16:25:41 <fantasai> stearns: I can define this in Shapes, specifically
16:25:48 <fantasai> stearns: Or we can put it in CSS images, for the image type in general
16:25:58 <fantasai> stearns: I think that's really the only question -- where should it be defined?
16:26:08 <fantasai> rossen: I don't care that this is part of Shapes
16:26:29 <fantasai> stearns: Any other opinions?
16:26:38 <fantasai> stearns: I'll put it into Shapes
16:26:53 <fantasai> fantasai: If we need to factor it out later, we can do that later
16:26:57 <glazou> http://lists.w3.org/Archives/Public/www-style/2013Jun/0514.html
16:26:59 <fantasai> RESOLVED: Define CORS stuff for shapes in Shapes
16:27:01 <Zakim> -SimonSapin
16:27:24 <fantasai> stearns: People in SVG want to point to some future CSS work for what they want to do
16:27:24 <SimonSapin> sorry about that
16:27:29 <fantasai> stearns: particularly wrt shape-inside
16:27:37 <fantasai> stearns: though not on anyone's plate to do that right atm
16:27:49 <fantasai> stearns: Proposed to take what's on the wiki page, make a Shapes Level 2 draft
16:27:50 <Zakim> +??P10
16:27:53 <fantasai> glazou: No problem with that
16:28:00 <SimonSapin> Zakim, ??P10 is me
16:28:00 <Zakim> +SimonSapin; got it
16:28:12 <fantasai> 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
16:28:15 <fantasai> glazou: other opinions?
16:28:34 <fantasai> RESOLVED: Shapes L2 ED agreed
16:28:45 <glazou> http://lists.w3.org/Archives/Public/www-style/2013Jun/0514.html
16:28:49 <bradk> bradk has joined #css
16:29:02 <fantasai> topic: Grid Auto-placement Algorithm
16:29:22 <bkardell> is that meant to be a link to grid?
16:29:38 <stearns> http://dev.w3.org/csswg/css-grid/#auto-placement-algo
16:29:44 <glazou> yes, sorry, bad url
16:29:47 <fantasai> 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.)
16:30:10 <fantasai> fantasai: Two ways to do auto-placement
16:30:20 <fantasai> fantasai: Sparse packing... you start in the 1, 1 slot
16:30:28 <fantasai> fantasai: and then place the next item that fist
16:30:35 <glazou> s/fist/fits
16:30:41 <fantasai> fantasai: move to the next empty slot, and put the next item
16:30:56 <fantasai> fantasai: If something doesn't fit you keep moving until you find an empty slot that's big enough
16:31:00 <fantasai> rossen: how do you define fit?
16:31:01 <dbaron> Rossen: how do you define "fit"?
16:31:09 <dbaron> fantasai: the span -- the number of cells
16:31:11 <fantasai> fantasai: Number of cells
16:31:49 <dbaron> 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.
16:31:55 <dbaron> fantasai: (etc.)
16:32:02 <dbaron> fantasai: so you leave behind a bunch of holes
16:32:11 <dbaron> Rossen: so it doesn't fit based on the number of columns, not based on sizing properties?
16:32:14 <dbaron> fantasai: right
16:32:28 <dbaron> fantasai: That's the sparse packing option.  Advantage of that is that things are in the order they appear.
16:32:36 <dbaron> fantasai: Other option is dense packing, which says you go back
16:32:53 <dbaron> 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.
16:33:03 <dbaron> fantasai: Advantage is no holes, disadvantage is that things get out of order.
16:33:24 <dbaron> fantasai: When we discussed at Microsoft, thought it made more sense to do sparse packing, at least for this level.
16:33:33 <dbaron> fantasai: Sparse packing is simpler, and don't get unexpected out-of-order.
16:33:45 <bkardell> I like the idea of dense packing as an option later
16:33:47 <dbaron> fantasai: We have the option of adding a way to turn on dense packing in a later level.
16:33:55 <Zakim> +SteveZ.a
16:34:10 <Zakim> -SteveZ
16:34:18 <dbaron> 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).
16:34:24 <dbaron> bradk: would that be based on the 'order' property?
16:34:31 <dbaron> bradk: ???
16:34:38 <dbaron> fantasai: Yeah, the order used is the order-modified document order.
16:34:47 <dbaron> ?: what's default of 'order'?
16:34:49 <dbaron> fantasai: 0
16:34:54 <stearns> +1 to default to sparse, with an optional switch for dense
16:35:18 <dbaron> bradk: order is for the ???, not for the ??? itself, right?
16:35:38 <dbaron> fantasai: couldn't hear
16:35:50 <dbaron> bradk: was just saying that if ... then it would be sparsely packed, otherwise densely packed
16:35:57 <dbaron> stearns: <missed>
16:36:09 <dbaron> bradk: but you could have order be something that overrides the dense packing
16:36:15 <bkardell> grid-visual-order?
16:36:15 <dbaron> stearns: I don't think this should be related.
16:36:28 <dbaron> stearns: order property just changes the dom order and that's the only affect it should have on the packing algorithm
16:36:44 <dbaron> Rossen: Think of order as a pre-order .... reordering the elements.  Before layout.
16:36:47 <c_palmer> c_palmer has joined #css
16:36:53 <stearns> s/affect/effect/ :)
16:36:54 <dbaron> bradk: could imply the author's intent to keep them in that order
16:37:01 <dbaron> Rossen: they are being kept in that order
16:37:08 <dbaron> bradk: ok, then.  I don't feel strongly.
16:37:31 <dbaron> Rossen: <inaudible about not being able to ... examples>
16:37:46 <dbaron> Rossen: From impl pov ...; but definitely easier to explain.
16:37:48 <Zakim> + +1.917.623.aaee
16:38:08 <dbaron> Rossen: ... float layout... position float, if not enough space, push below until find space.  You never backtrack.
16:38:12 <c_palmer> Zakim, 1.917.623.aaee is me
16:38:12 <Zakim> sorry, c_palmer, I do not recognize a party named '1.917.623.aaee'
16:38:40 <c_palmer> Zakim, +1.917.623.aaee is me
16:38:40 <Zakim> +c_palmer; got it
16:38:43 <dbaron> 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.
16:39:04 <dbaron> Rossen: so should we go with sparse?
16:39:10 <dbaron> bradk: I don't feel strongly.
16:39:12 <dbaron> glazou: I think we should.
16:39:32 <dbaron> RESOLVED: sparse packing for grid auto position
16:39:48 <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013AprJun/0287.html
16:39:52 <krit> file:///Users/dschulze/Documents/hg/FXTF/masking/index.html
16:40:02 <krit> http://dev.w3.org/fxtf/masking/
16:40:32 <krit> http://dev.w3.org/fxtf/masking/#box-image-masks
16:40:34 <glazou> fantasai, lol
16:40:58 <SimonSapin> ScribeNick: SimonSapin
16:40:59 <dbaron> Topic: mask/mask-box-image shorthand
16:41:22 <SimonSapin> krit: shorthand is bad
16:41:30 <dbaron> krit: request from fantasai about making one mask property that turns off all masking
16:41:49 <dbaron> krit: fantasai wanted mask to reset mask-box-image etc.
16:41:52 <krit> http://lists.w3.org/Archives/Public/www-style/2013Jun/0645.html
16:41:55 <SimonSapin> krit: fantasai requested that 'mask' also reset 'mask-image' and related properties
16:42:01 <fantasai> krit: Request led to new design for mask properties
16:42:08 <fantasai> krit: where 'mask' would be overall shorthand for all masking properties
16:42:14 <fantasai> krit: here's a link for how it could look like
16:42:22 <fantasai> krit: we would have mask-layers, which would be like 'background' shorthand
16:42:32 <fantasai> krit: and we would have mask-element, which does svg references
16:42:41 <fantasai> krit: and then mask-box, like box-image
16:42:50 <fantasai> krit: seem to have agreement on overall structure
16:42:53 <plh> q?
16:42:56 <fantasai> krit: question is, what is the shorthand able to set
16:42:56 <plh> queue=
16:43:18 <fantasai> krit: shorthand similar to 'border' shorthand -- resets all border properties, but not able to set border-image properties
16:43:24 <Zakim> -jdaggett
16:43:30 <fantasai> krit: My proposal is to have 'mask' only set mask-element
16:43:35 <fantasai> krit: It already does that
16:43:52 <fantasai> krit: and it's hard to distinguish URLs for different things, so hard to add in anything other than mask-element reference
16:44:06 <fantasai> smfr: So, you're saying if you use 'mask' shorthand, can't set both mask-box and mask-layers?
16:44:16 <fantasai> smfr: So you have mutually-exclusive options in a shorthand... which is confusing to me
16:44:38 <fantasai> florian: It does happen, not that rarely, that you can do basic things in shorthand and other things need to go to longhand
16:45:01 <fantasai> krit: fantasai would like to also allow mask-box / mask-layers into shorthand
16:45:13 <fantasai> krit: but this leads to parsing problems, because url() is ambiguous
16:45:30 <fantasai> smfr: Sounds like it would be a very confusing shorthand
16:45:39 <fantasai> krit: Problem is really that these all use url() function
16:45:58 <fantasai> krit: Need to distinguish which property you want to assign the url() to at parse time
16:46:14 <fantasai> krit: One idea was to check for fragID, assume it's an element
16:46:20 <fantasai> krit: But request that we don't do that
16:46:24 <fantasai> florian: No, that doesn't seem pretty
16:46:34 <fantasai> smfr: So saying mask-layers is not part of shorthand at all?
16:46:41 <fantasai> smfr: But can reset the masks with the shorthand?
16:46:50 <fantasai> florian: shorthand can only set 'none'
16:46:53 <fantasai> smfr: So confusing
16:47:00 <fantasai> smfr: properties interact in non-symmetrical ways
16:47:11 <SimonSapin> 'border' also resets 'border-image' but can not set it
16:47:12 <fantasai> krit: mask-layers is already a shorthand
16:47:22 <fantasai> smfr: I think this adds too much confusion for something that won't be used very often
16:47:36 <fantasai> krit: Even without this, still kindof hacky
16:47:43 <fantasai> krit: because of 'mask' setting SVG masks right now
16:47:50 <fantasai> florian: This doesn't bother me much
16:48:03 <fantasai> glazou: Opinions here? smfr thinks undesirable?
16:48:12 <fantasai> smfr: Think it's too much complexity to get one part of behavior
16:48:14 <fantasai> florian: I'm ok with it
16:48:39 <fantasai> krit: If we don't do this, we still need a way to distinguish mask element and mask layers
16:49:03 <fantasai> ?: Is this just about having top-level shorthand support none | <mask-element> ?
16:49:10 <fantasai> smfr: mask-element is the svg-style one
16:49:20 <fantasai> s/?/bkardell/
16:49:28 <fantasai> smfr: not represented in WebKit prefixed version
16:49:36 <fantasai> smfr: Which are possibly used more often than SVG one
16:49:40 <fantasai> krit: Might be right
16:49:48 <fantasai> glazou: What should we do now?
16:50:14 <fantasai> krit: 'mask: <mask-element> | none' is part of SVG REC
16:50:36 <fantasai> ??: if I understand correctly, question is, either there is no mask shorthand directly
16:50:45 <glazou> s/??/bkardell
16:50:46 <fantasai> ??: Or, is it this limitation of mask-element || none?
16:51:11 <fantasai> krit: We have this mask property already, which points to SVG. So either way, we need a way to handle this back-compat situation
16:51:31 <fantasai> bkardell: I like ability to say 'none' at the shorthand level
16:51:46 <fantasai> florian: I really don't like parse-the-url thing
16:51:56 <fantasai> florian: Everything else so far, I'm comfortable with, but that I'd like to avoid
16:52:35 <fantasai> krit: I don't think smfr's proposal is possible.
16:52:47 <fantasai> smfr: Just have 3 separate properties
16:52:56 <bkardell> not possible even if it can only do none?
16:52:56 <fantasai> krit: mask-element will have to be called just 'mask', then
16:53:08 <fantasai> krit: because we already have this property in spec + implementations
16:53:29 <fantasai> [basically, 'mask: none | <uri>' has to work somehow ]
16:54:09 <fantasai> fantasai: I guess one thing to think about is, is there anything we can do in the shorthand that would let us distinguish the longhands in it
16:54:13 <glazou> http://lists.w3.org/Archives/Public/www-style/2013Jun/0276.html
16:54:18 <fantasai> Topic: painting area & bg-attachment: local
16:54:46 <fantasai> SimonSapin: Decided recently, positioning area of bg-attachment: local is the scrolling area
16:54:52 <fantasai> SimonSapin: Think it should be the same for the clipping area
16:55:00 <fantasai> SimonSapin: If we consider the background is inside the scoll box
16:55:14 <fantasai> SimonSapin: It should also keep the same as the content, that is the padding box
16:55:27 <fantasai> SimonSapin: So intersection of rectangle based on bg property and clipping property
16:55:36 <fantasai> glazou: Opinions?
16:55:41 <plh> rrsagent, generate minutes
16:55:41 <RRSAgent> I have made the request to generate http://www.w3.org/2013/07/10-css-minutes.html plh
16:55:44 <fantasai> smfr: What is the visible difference
16:56:00 <fantasai> SimonSapin: Mostly when you have bg-clip: content-box; and some padding
16:56:15 <fantasai> SimonSapin: You have some area that has no background at the top, but when you scroll that area disappears
16:56:36 <fantasai> SimonSapin: but if you consider that the clipping area is not scrolling, then you always have this padding not scrolling as well
16:56:49 <fantasai> smfr: I think I understand, but would love testcases / diagrams
16:57:00 <Zakim> -??P61
16:57:04 <fantasai> fantasai: I totally agree, this is obviously the right thing to do
16:57:07 <bkardell> lgtm
16:57:19 <glazou> bkardell, lgtm???
16:57:26 <fantasai> smfr: seems you'd use different clipping for different bg layers based on whether local or not
16:57:30 <bkardell> looks good to me
16:57:38 <fantasai> smfr: Would make implementations a little more complex
16:57:43 <fantasai> SimonSapin: Possibly
16:57:58 <fantasai> SimonSapin: Currently working on patch for that in Gecko. Not a problem for us, though might depend on architecture
16:58:15 <fantasai> glazou: Anyone objecting?
16:58:18 <bradk> Should it also depend on presense of scrollbars?
16:58:20 <fantasai> smfr: I would like diagrams
16:58:33 <fantasai> glazou: OK, revisit next week
16:58:45 <fantasai> glazou: And we have 1 minute on the call... anything else for 1 miute?
16:59:02 <Zakim> -dbaron
16:59:02 <Zakim> -sgalineau
16:59:03 <Zakim> -SteveZ.a
16:59:03 <Zakim> -krit
16:59:03 <Zakim> - +1.520.280.aadd
16:59:04 <Zakim> -SimonSapin
16:59:04 <Zakim> -glazou
16:59:05 <Zakim> -antonp
16:59:05 <Zakim> -Stearns
16:59:06 <Zakim> -c_palmer
16:59:06 <Zakim> -koji
16:59:08 <Zakim> -fantasai
16:59:08 <Zakim> -jerenkrantz
16:59:08 <Zakim> -BradK
16:59:10 <Zakim> -plinss
16:59:10 <Zakim> -glenn
16:59:12 <Zakim> -Plh
16:59:14 <jerenkrantz_> jerenkrantz_ has left #css
16:59:16 <Zakim> -[IPcaller]
16:59:19 <bradk> bradk has left #css
16:59:24 <SimonSapin> smfr: the diagrams should be the same as for the positioning area
16:59:34 <SimonSapin> s/smfr:/smfr,/
16:59:35 <Zakim> -shezbaig_wk
16:59:37 <Zakim> -smfr
16:59:49 <smfr> SimonSapin: where are those?
16:59:51 <SimonSapin> but I could make more with padding and border-radius, if that helps
17:00:11 <SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013May/0542.html
17:00:36 <Zakim> -MaRakow
17:01:18 <smfr> SimonSapin: it would help I think
17:01:41 <smfr> i'm a bit worried about implementation complexity
17:01:59 <smfr> gtg
17:03:40 <Zakim> -rhauck
17:04:12 <SimonSapin> SimonSapin has joined #css
17:07:41 <plh> florian, does this look ok to you? http://www.w3.org/Style/2012/REC-mediaqueries-20120619-errata.html
17:08:40 <Zakim> disconnecting the lone participant, Lea, in Style_CSS FP()12:00PM
17:08:41 <Zakim> Style_CSS FP()12:00PM has ended
17:08:41 <Zakim> Attendees were glazou, jerenkrantz, plinss, jdaggett, Stearns, fantasai, Plh, +1.206.675.aaaa, glenn, SimonSapin, smfr, shezbaig_wk, +1.415.615.aabb, antonp, SteveZ, rhauck,
17:08:42 <Zakim> ... dbaron, sgalineau, +1.415.832.aacc, florian, krit, BradK, [IPcaller], MaRakow, koji, Lea, +1.520.280.aadd, c_palmer
17:30:38 <rhauck> rhauck has joined #css
17:45:35 <c_palmer> c_palmer has joined #css
18:02:50 <stearns> stearns has joined #css
18:21:35 <rhauck> rhauck has joined #css
18:24:32 <SimonSapin> SimonSapin has joined #css
19:00:00 <Zakim> Zakim has left #css
19:18:29 <krit> krit has joined #css
19:31:32 <tantek> tantek has joined #css
19:56:53 <lmclister> lmclister has joined #css
19:59:25 <dbaron> dbaron has joined #css
20:00:00 <abucur_> abucur_ has joined #css
20:26:22 <dbaron> dbaron has joined #css
20:26:54 <krit> krit has joined #css
20:29:12 <hober> hober has joined #css
21:10:23 <dbaron> dbaron has joined #css
22:57:57 <TabAtkins> plinss: How do you determine the name of a spec in shepherd?  Manually?
22:58:16 <TabAtkins> plinss: I'm wondering what the name formats will be, so I can reliably extract them into a shortname and a level.
22:59:13 <plinss> TabAtkins: the spec names are created when whoever adds the spec to the db, so it's just a name that's picked
22:59:22 <plinss> the intent is to use the shortname
22:59:36 <plinss> but that's not enforced (and they're all changing anyway…)
23:00:20 <TabAtkins> plinss: Okay.  Ideally the spec data file would have shortname and level as separate fields, so I can let people choose which spec to ref more easily.
23:00:21 <plinss> if you want to find the shortname, I suggest parsing it from the spec's url
23:00:37 <TabAtkins> kk
23:01:30 <plinss> hmm, I suppose I could add the level (and just call the name the shortname)
23:03:47 <TabAtkins> No, the name field is a bizarre mix of leveled and unleveled things.
23:03:53 <plinss> but I'm thinking that for what you're thinking the shortname wouldn't include the level?
23:04:17 <TabAtkins> Yeah.
23:04:45 <TabAtkins> I want to allow, in the source file, someone to indicate a ref really simply with a custom element like <ref spec=css-fonts level=4>...</ref>.
23:04:58 <TabAtkins> (It'll get converted into an <a> with attributes set up correctly.)
23:05:17 <plinss> why?
23:05:20 <TabAtkins> (This'll only be necessary when there's a conflict in terms that I can't auto-resolve, anyway.)
23:05:44 <plinss> as in, why are you treating the level as something separate?
23:05:57 <plinss> would you ever have a spec and not specify the level?
23:06:01 <TabAtkins> Sometimes you want to link to a particular module?
23:06:06 <TabAtkins> Yeah, if you just want to link to the latest.
23:06:11 <TabAtkins> Which is the common mode.
23:09:49 <plinss> fwiw, I'm planning on cleaning up all the spec names in shepherd to match the new shortname convention (I just have to add support for urls with the old names in them)
23:10:13 <plinss> I can do that sooner if you're dependent on it
23:10:55 <TabAtkins> I will be dependent on it, but I'm leaving for the day to go drinking now anyway, so whatever.
23:11:26 <plinss> k, I'll get that online in a day or two
23:12:02 <TabAtkins> Cool.
23:27:51 <fantasai> glenn: btw, I keep meaning to say and forgetting -- thanks for the cough drops in Tokyo! they really helped~
23:28:34 <glenn> ah, yeah, you seemed in a bad way; i always carry a couple of bags of ricola on trips (along with a couple of boxes of Zithromax just in case)
23:28:40 <sgalineau> sgalineau has joined #css
23:29:00 <glenn> glad you recovered
23:29:11 <fantasai> :)
23:52:43 <jdaggett> jdaggett has joined #css