<glazou> http://www.w3.org/TR/its20/#its-param

<fantasai> ScribeNick: fantasai

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

text-combine-horizontal

<glazou> http://lists.w3.org/Archives/Public/www-style/2013Jul/0111.html

jdaggett: Last week there was a resolution about the algorithm
... 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
... Posted some examples
... Example of 107
... showing scaling vs. variants
... This is imporant because font designer put this into the font
... UA shouldn't be synthesizing things
... UA should be required to use the variants
... Arguments about cases where other behaviors might be better
... Based purely on scaling, will produce different results based on width of glyphs
... See, e.g. second URL
... alphabetic text
... case 5, scaling only
... IA looks normal, but MM looks much lighter
... It will make a difference in readability
... Whereas case 4 has the right weight
... This is already what implementations are doing
... Would like this to be the required behavior, so we can actually test it

<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

fantasai: We can test things that aren't required.
... We do this in other places

florian: Case of #12, some glyphs have variant and some don't
... Think we should say this case is undefined
... Do we all agree on this?

jdaggett: I'm fine to say, use width variants if all characters have width variants

rossen: I agree with jdaggett. When we implemented text-combine-horizontal, we assumed that if the font provides glyphs, then we should use those
... And not create a crappy-locking solution just because we can do it cheaper
... Have a question, when we are going to require that we use the font variants
... Are we talking about digits, or regardless of which text-combine-horizontal we're using?
... e.g. case of text-combine: all, only 3 characters
... would we also consider those?

fantasai: Considering any case

florian: jdaggett made case that if font designer made glyphs available, should use them
... Question, are these glyphs designed only for TCY?
... There was also the case that these glyphs force monospace design
... But in some cases proportional width might be better
... Here we are not explicitly asking for half-width, you're asking for TCY
... Easy to see these two things are related, but not necessarily 1-1 mappin

g

http://dev.w3.org/csswg/css-writing-modes/#text-combine-horizontal

Current text, btw

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]

[some amount of argument over the 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.

jdaggett: If you scale based on width of 2-char proportional span, this will result in variations in scaling factor
... which gives poor readability

koji: I think you misunderstood what fantasai said

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

koji: Both she and I agree that width variants is better than scaling
... 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
... 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

I suggest A' as an example where hwid would not be good

White space in MQ

<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
... @suports requires space between ')', 'and'
... We decided to make this the same
... Missed on some subtleties
... One is that, unlike @supports, not everything is between parens

<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

florian: e.g. @media screen and (min-width: ...)
... Currently we don't require a space between 'screen' and 'and' -- you could put a comment
... To make things clean, suggest just requiring space there.
... Also @supports not ... requires space after not, MQ doesn't...
... Proposal is to harmonize all that
... by requiring spaces
... I proposed a new grammar; dbaron proposed a better grammar
... 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?

RESOLUTION: Accepted

dbaron: Another comment --
... 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.
... 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.

RESOLUTION: Whoever updates errata doc, must send update message to www-style.

jdaggett: Quick question...
... There was a request to publish LC of Fonts. Is anyone going to do it?
... There was a request to publish... and no response from anybody

plh: I'll check; currently transitioning webmasters
... I'll double-checkon that.

Cross-origin style sheets

glazou: Anyone able to handle that? No one from Opera?

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
... My understanding is that we need to define a [..] mechanism where you pass a CORS flag and get a response that [..]
... I can define this in Shapes, specifically
... Or we can put it in CSS images, for the image type in general
... I think that's really the only question -- where should it be defined?

rossen: I don't care that this is part of Shapes

stearns: Any other opinions?
... I'll put it into Shapes

fantasai: If we need to factor it out later, we can do that later

<glazou> http://lists.w3.org/Archives/Public/www-style/2013Jun/0514.html

RESOLUTION: Define CORS stuff for shapes in Shapes

stearns: People in SVG want to point to some future CSS work for what they want to do

<SimonSapin> sorry about that

stearns: particularly wrt shape-inside
... though not on anyone's plate to do that right atm
... Proposed to take what's on the wiki page, make a Shapes Level 2 draft

glazou: No problem with that
... Most of what you added was already in the L1 drafts. Not as if we never agreed to work on that. So in favor
... other opinions?

RESOLUTION: Shapes L2 ED agreed

<glazou> http://lists.w3.org/Archives/Public/www-style/2013Jun/0514.html

Grid Auto-placement Algorithm

<bkardell> is that meant to be a link to grid?

<stearns> http://dev.w3.org/csswg/css-grid/#auto-placement-algo

<glazou> yes, sorry, bad url

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
... Sparse packing... you start in the 1, 1 slot
... and then place the next item that fits
... move to the next empty slot, and put the next item
... If something doesn't fit you keep moving until you find an empty slot that's big enough

rossen: how do you define fit?

<dbaron> Rossen: how do you define "fit"?

<dbaron> fantasai: the span -- the number of cells

fantasai: Number of cells

<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.

<dbaron> fantasai: (etc.)

<dbaron> fantasai: so you leave behind a bunch of holes

<dbaron> Rossen: so it doesn't fit based on the number of columns, not based on sizing properties?

<dbaron> fantasai: right

<dbaron> fantasai: That's the sparse packing option. Advantage of that is that things are in the order they appear.

<dbaron> fantasai: Other option is dense packing, which says you go back

<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.

<dbaron> fantasai: Advantage is no holes, disadvantage is that things get out of order.

<dbaron> fantasai: When we discussed at Microsoft, thought it made more sense to do sparse packing, at least for this level.

<dbaron> fantasai: Sparse packing is simpler, and don't get unexpected out-of-order.

<bkardell> I like the idea of dense packing as an option later

<dbaron> fantasai: We have the option of adding a way to turn on dense packing in a later level.

<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).

<dbaron> bradk: would that be based on the 'order' property?

<dbaron> bradk: ???

<dbaron> fantasai: Yeah, the order used is the order-modified document order.

<dbaron> ?: what's default of 'order'?

<dbaron> fantasai: 0

<stearns> +1 to default to sparse, with an optional switch for dense

<dbaron> bradk: order is for the ???, not for the ??? itself, right?

<dbaron> fantasai: couldn't hear

<dbaron> bradk: was just saying that if ... then it would be sparsely packed, otherwise densely packed

<dbaron> stearns: <missed>

<dbaron> bradk: but you could have order be something that overrides the dense packing

<bkardell> grid-visual-order?

<dbaron> stearns: I don't think this should be related.

<dbaron> stearns: order property just changes the dom order and that's the only affect it should have on the packing algorithm

<dbaron> Rossen: Think of order as a pre-order .... reordering the elements. Before layout.

<stearns> s/affect/effect/ :)

<dbaron> bradk: could imply the author's intent to keep them in that order

<dbaron> Rossen: they are being kept in that order

<dbaron> bradk: ok, then. I don't feel strongly.

<dbaron> Rossen: <inaudible about not being able to ... examples>

<dbaron> Rossen: From impl pov ...; but definitely easier to explain.

<dbaron> Rossen: ... float layout... position float, if not enough space, push below until find space. You never backtrack.

<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.

<dbaron> Rossen: so should we go with sparse?

<dbaron> bradk: I don't feel strongly.

<dbaron> glazou: I think we should.

<dbaron> RESOLVED: sparse packing for grid auto position

<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013AprJun/0287.html

<krit> file:///Users/dschulze/Documents/hg/FXTF/masking/index.html

<krit> http://dev.w3.org/fxtf/masking/

<krit> http://dev.w3.org/fxtf/masking/#box-image-masks

<glazou> fantasai, lol

<SimonSapin> ScribeNick: SimonSapin

mask/mask-box-image shorthand

krit: shorthand is bad

<dbaron> krit: request from fantasai about making one mask property that turns off all masking

<dbaron> krit: fantasai wanted mask to reset mask-box-image etc.

<krit> http://lists.w3.org/Archives/Public/www-style/2013Jun/0645.html

krit: fantasai requested that 'mask' also reset 'mask-image' and related properties

<fantasai> krit: Request led to new design for mask properties

<fantasai> krit: where 'mask' would be overall shorthand for all masking properties

<fantasai> krit: here's a link for how it could look like

<fantasai> krit: we would have mask-layers, which would be like 'background' shorthand

<fantasai> krit: and we would have mask-element, which does svg references

<fantasai> krit: and then mask-box, like box-image

<fantasai> krit: seem to have agreement on overall structure

<fantasai> krit: question is, what is the shorthand able to set

<fantasai> krit: shorthand similar to 'border' shorthand -- resets all border properties, but not able to set border-image properties

<fantasai> krit: My proposal is to have 'mask' only set mask-element

<fantasai> krit: It already does that

<fantasai> krit: and it's hard to distinguish URLs for different things, so hard to add in anything other than mask-element reference

<fantasai> smfr: So, you're saying if you use 'mask' shorthand, can't set both mask-box and mask-layers?

<fantasai> smfr: So you have mutually-exclusive options in a shorthand... which is confusing to me

<fantasai> florian: It does happen, not that rarely, that you can do basic things in shorthand and other things need to go to longhand

<fantasai> krit: fantasai would like to also allow mask-box / mask-layers into shorthand

<fantasai> krit: but this leads to parsing problems, because url() is ambiguous

<fantasai> smfr: Sounds like it would be a very confusing shorthand

<fantasai> krit: Problem is really that these all use url() function

<fantasai> krit: Need to distinguish which property you want to assign the url() to at parse time

<fantasai> krit: One idea was to check for fragID, assume it's an element

<fantasai> krit: But request that we don't do that

<fantasai> florian: No, that doesn't seem pretty

<fantasai> smfr: So saying mask-layers is not part of shorthand at all?

<fantasai> smfr: But can reset the masks with the shorthand?

<fantasai> florian: shorthand can only set 'none'

<fantasai> smfr: So confusing

<fantasai> smfr: properties interact in non-symmetrical ways

'border' also resets 'border-image' but can not set it

<fantasai> krit: mask-layers is already a shorthand

<fantasai> smfr: I think this adds too much confusion for something that won't be used very often

<fantasai> krit: Even without this, still kindof hacky

<fantasai> krit: because of 'mask' setting SVG masks right now

<fantasai> florian: This doesn't bother me much

<fantasai> glazou: Opinions here? smfr thinks undesirable?

<fantasai> smfr: Think it's too much complexity to get one part of behavior

<fantasai> florian: I'm ok with it

<fantasai> krit: If we don't do this, we still need a way to distinguish mask element and mask layers

<fantasai> ?: Is this just about having top-level shorthand support none | <mask-element> bkardell

<fantasai> smfr: mask-element is the svg-style one

<fantasai> smfr: not represented in WebKit prefixed version

<fantasai> smfr: Which are possibly used more often than SVG one

<fantasai> krit: Might be right

<fantasai> glazou: What should we do now?

<fantasai> krit: 'mask: <mask-element> | none' is part of SVG REC

<fantasai> bkardell: if I understand correctly, question is, either there is no mask shorthand directly

<fantasai> ??: Or, is it this limitation of mask-element || none?

<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

<fantasai> bkardell: I like ability to say 'none' at the shorthand level

<fantasai> florian: I really don't like parse-the-url thing

<fantasai> florian: Everything else so far, I'm comfortable with, but that I'd like to avoid

<fantasai> krit: I don't think smfr's proposal is possible.

<fantasai> smfr: Just have 3 separate properties

<bkardell> not possible even if it can only do none?

<fantasai> krit: mask-element will have to be called just 'mask', then

<fantasai> krit: because we already have this property in spec + implementations

<fantasai> [basically, 'mask: none | <uri>' has to work somehow ]

<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

<glazou> http://lists.w3.org/Archives/Public/www-style/2013Jun/0276.html

painting area & bg-attachment: local

<fantasai> SimonSapin: Decided recently, positioning area of bg-attachment: local is the scrolling area

<fantasai> SimonSapin: Think it should be the same for the clipping area

<fantasai> SimonSapin: If we consider the background is inside the scoll box

<fantasai> SimonSapin: It should also keep the same as the content, that is the padding box

<fantasai> SimonSapin: So intersection of rectangle based on bg property and clipping property

<fantasai> glazou: Opinions?

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/look/lock/
Succeeded: s/fist/fits/
WARNING: Bad s/// command: s/affect/effect/ :)
Succeeded: s/?/bkardell/
Succeeded: s/??/bkardell/
Found ScribeNick: fantasai
Found ScribeNick: SimonSapin
Inferring Scribes: fantasai, SimonSapin
Scribes: fantasai, SimonSapin
ScribeNicks: fantasai, SimonSapin

WARNING: No "Present: ... " found!
Possibly Present: BradK IPcaller JohnJansen_ Lea MaRakow Microsoft P10 P19 P48 P50 P61 P64 P97 Rossen ScribeNick SimonSapin SteveZ aaaa aabb aacc aadd aaee antonp bkardell c_palmer dbaron fantasai file florian glazou glenn https jdaggett jerenkrantz jerenkrantz_ koji krit lmclister plh plinss rhauck rhauck1 sgalineau shezbaig_wk smfr stearns tantek
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 10 Jul 2013
Guessing minutes URL: http://www.w3.org/2013/07/10-css-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.