[CSSWG] Minutes and Resolutions Seattle F2F 2011-07-25 AM: CSSOM, Regions, Floats/Exclusions

CSSOM
-----

   - Discussed scope of CSSOM spec wrt new features
   - Discussed interaction of CSSOM with other modules
   - Anne needs more implementer feedback on the draft
   - WG needs more developer feedback on what's needed
   - RESOLVED: Publish update of CSSOM View module

CSS Regions
-----------

   - RESOLVED: Copying Flow Content is not something we are looking at right now.
   - RESOLVED: Change the grid to integrate with css regions through regular
               elements
   - RESOLVED: Stick to content property and content: from-flow(<flow-name>)
   - RESOLVED: change flow to flow-smthing
   - RESOLVED: rename content: from-flow to content: flow-from
     (Note: there's a comment after the resolution in the minutes expressing disagreement.)
   - Discussed intrinsic sizing and auto sizing of regions
   - RESOLVED: for this version we are limiting regions to be block containers; will
               add a note that this may be expanded in future levels
   - RESOLVED: we need breaks that are specific to containers they are part of;
               still need a proposal for this
   - Discussion if iframe behavior in spec and how it relates to HTML5 seamless

CSS Exclusions
--------------

   - Discussion of the processing model, scope of exclusions' effect, interaction
     with z-index, shrink-to-fit, etc.

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

<RRSAgent> logging to http://www.w3.org/2011/07/25-css-irc

Present:
   +Rossen Atanassov (Microsoft)
   +Phil Cupp (Microsoft)
   +John Daggett (Mozilla) via phone + IRC (afternoon-only)
   +Simon Fraser (Apple)
   +Chris Lilley (W3C) via phone + IRC
   +Brian Manthos (Microsoft)
   +Nat McCully (Adobe)
   +Doug Schepers (W3C)

CSSOM
-----
ScribeNick: Divya

   glazou: report whats going on with CSSOM, what are the stuff we need to
           add, change.
   glazou: anne, tell us where you are right now, what you need to add,
           change, etc
   anne: the OM covers how to serialize mediaq, selectors, stylesheets in
         general
   <sylvaing> http://dev.w3.org/csswg/cssom/
   anne: it has alt stylesheet api so people can control stylesheet sets
         from scripts.
   anne: it def processing requirements for the link header so you can
         associate stylesheets with documents via http
   anne: it then defines the "real" OM all the stylesheet rules and their apis
   anne: e.g. @import, @media, font-face, etc
   anne: there is a new thing called the values api, so far OM has been
         string based.
   anne: in 2003 we obsoleted parts of DOM level2 style that were object
         based but never wrote a replacement, section 6.6 in CSSOM draft
         sketches out how Object based API would look
   anne: lacking: implementors need to look at it to poke holes in idea
         before we formally define it.
   anne: this was the case a year ago, so people have not gotten around
         to looking at it yet
   anne: there is a priority of list of features, e.g. to get to resolved
         styles of elements.
   anne: I would like to not add too much features before current features
         are interoperably implemented.

   anne: we need to find out a plan on how to, since css is fairly modularized,
         how we do the same for the OM
   anne: if we get interfaces for components like colors, it would be best
         if they are defined in their respective drafts.
   anne: it would mean those drafts would have some dependency on the OM
   fantasai: could we split out the serialization into its own parallel module
   smfr: for css transforms we need to expose an api for matrix transformations.
   anne: the color module needs to expose an api.
   anne: its not just serialisation but the whole…
   anne: each draft that defines a "bracketed new thing", needs to define an
         interface to it as well.
   fantasai: two ways to do that
   fantasai: have it paired with the module to define OM stuff
   fantasai: for drafts that are advanced publish a .1 which includes OM stuff
   fantasai: e.g. css color 3.1 or css color object model.
   fantasai: in some cases the editor of the module can do the OM stuff but in
             other cases the editor might not have the expertise, so we need
             two editors or more.
   florian: if we have 3, 3.1, and 4 some people can get confused
   anne: maybe we have it into 4.
   anne: I think its best if its in same module as def and such will be tightly
         coupled
   fantasai: going forward we can do that, but for some specs we can't do that;
             already too far advanced
   anne: maybe put them into 4 for current specs that you can't change.

   florian: it might be quite a while before it becomes stable
   fantasai: another problem with OM is that it might hold back development
             of rest of the spec.
   anne: we might have to separate them
   fantasai: we can cross-link the documents
   arronei: we might have conformance problem too, as OM is not necessary for
            implementations
   fantasai: suggestion to go with separate modules but paired, if we want to
             merge we can merge them later.
   mollydotcom: what does it look like.
   fantasai: One CSS3 Color Module and one CSS3 Color Object Model Module
   vhardy: for specs like css3 regions which have a little bit of OM in them,
           keep them in the spec rather than splitting

   glazou: apart from css values, this doc is specification of current
           implementation, what are the plans for the future?
   glazou: I am a heavy user of OM it is not practical at this point
   anne: it needs improvements but we need more tests for existing stuff first.
   anne: it has better def for DOM level 2 styles, which lacked a lot of details
   glazou: everybody knows that OM is resolved, its probably time to push for
           new things.
   anne: making it more interoperably and finding more stuff …
   glazou: if we do stabilization for the next 3 years, it requires commitment
           from editors, implementors. it would be more than 2 years before we
           implement the new stuff
   glazou: we are not able to serialise stylesheets, cssText.
   anne: those are minor features its not something developers really want
   glazou: they are not minor
   arronei: they maybe minor for devs, but not for web browsers
   glazou: people who are writing editors need to play with these things
           every day. we need to improve the OM for new services on the web
   anne: we have not defined serialization for most of the things. Just adding
         new things does not seem to be a good way forward.

   glazou: I know, we should start collecting new things we are doing to the
           OM, and what are the expectations from web authors.
   anne: sure getting feedback from web authors would be great
   <shepazu> (another interesting thing might be font/text metrics:
              http://lists.w3.org/Archives/Public/public-svg-wg/2010OctDec/0004.html)
   anne: better value api, once that is there, they want to have access to
         resolved vaules, there are various features browsers have added for
         their debugging tools, figure out which property calls current styles.
   glazou: what are the rules that are being called at a given time
   shepazu: in svg wg we have thought about adding font metric api, I thought
            it might be interesting
   anne: like in canvas?
   shepazu: the thing in canvas might be suitable why not generalize for
            general users
   dino: you do not exactly know thats the font being used.
   dino: all the canvas does is how long the piece of text was, does not tell
         you the ascenders,
   szilles: or where the baselines are
   shepazu: the things the canvas one does is useful
   shepazu: I suspect chris saying web fonts working group will be interested in
   anne: there have been requests for font loading api, but we have not
         figured out right way to do it
   vhardy: how do you capture requirements? do you have a place for that?
   anne: there is a page in whatwg wiki. we should probably create a place in
         csswg wiki
   glazou: long ago we had a list of suggestions for css3 we can have the
           list of suggestions for cssom
   <anne> http://wiki.csswg.org/spec/cssom
   sylvaing: do we have use cases?
   anne: it does not have much yet.

   florian: anne says stabilize, glazou says new features
   glazou: not new features now, but soon
   anne: I am also curious what implementors think, last year, we discussed this
   anne: TabAtkins said google was planning on experimenting on values api
   TabAtkins: we are still planning on it
   anne: it kinda depends on implementors as well how fast it will move forward
   anne: if there is not sufficient interest there is no point in adding a
         bunch of things and spend time on this if there are other things
         more interesting
   vhardy: would it make sense to get a list of features and get feedback
           from community. we have some input and prioritize which are important
   glazou: microsoft has been doing online applications using formats that
           are not based on w3c standards.
   glazou: the cost for that [feedback] is low
   glazou: anything else to decide [?] OM
   vhardy: first set of extensions and ask for feedback?
   glazou: no just ask for feedback

   shepazu: I would like people to see action to review it
   anne: that is more problematic than community input
   anne: we have got a few feedback like features like resolved value,
         authors want access to browser's proprietary extensions for their
         debugging tools
   anne: problem is getting implementors' attention.
   anne: I work for an implementor but I don't think opera can really drive this.
   glazou: user feedback can help. the feedback for css3 created traction.
   arronei: you have unique knowledge in the room, so your feedback would be
            useful
   <tantek> anne, are there particular web applications that would be helped
            (e.g. made faster, or new higher fidelity features) by more CSSOM
            features?
   glazou: cost of a single missing feature of OM can be about 2000 likes of
           code. as you start duplicating the cost becomes prohibitive. 2 or
           3 lines in c++ for 1000 lines of js
   ACTION: glazou collect feedback from webdev community for CSSOM and put
           it on the wiki http://wiki.csswg.org/spec/cssom
   <trackbot> Created ACTION-349
   <arno> let's get input from framework vendors as well (jQuery, Sencha, etc…)

   anne: can we do one more item
   anne: there is also the view module? can we publish it once more, so there
         is a link to the editor's draft
   fantasai: its already in the module template
   anne: since it is not published already, so it does not have that link
   szilles: he says the view module does not have the new template
   fantasai: we can publish then
   RESOLVED: Publish the CSSOM View module

   <tantek> possible classes of use-cases to drive CSSOM evolution: web app
            games, where greater responsiveness (speed) and higher fidelity
            experience are both desired.

CSS Regions
-----------

   vhardy: last meeting we decided to name it CSS Floats not Exclusions
   vhardy: there is a ED that has resolution from last f2f there is a wd
           that was published after f2f as well
   vhardy: wiki has a bunch of issues and use cases that we will go over
   alan hooked up the test harness and the spec references it now
   vhardy: next step is to go over the bunch of issues we have and pub
           together a new draft
   vhardy: for css exclusions we have the original draft same as kyoto
   vhardy: ms sent a proposal and glazou sent one over email
   vhardy: we tried to converge on the proposals and the next step is to
          resolve issues and produce new ED to propose as WD
   <smfr> http://wiki.csswg.org/spec/css3-regions

   vhardy: we discussed there was no formal resolution in previous meeting.
           there was a q on the amiling list if css regions should allow
           copying from element into flow instead of moving content into
           flow. the editors agree this is something we should move to
           future release might be interesting but more complicated, so
           proposal is not to do it now and see if there is consensus in
           not adding this feature at this time
   smfr: def agree on that
   RESOLVED: Copying Flow Content is not something we are looking at right now.

   vhardy: next issue is CSSOM issue. we don't have ability to find out
           which element is in a named flow
   vhardy: there is no way to find that out right now.
   vhardy: our proposal is to get an action item for alexmog and me to add
           to the next draft unless someone thinks this feature should not
           be in the draft
   florian: are you going to do this programmatically or declaratively
   smfr: that could be regions plural right
   vhardy: programatically, plural
   glazou: this will be useful for debugging tools
   ACTION: vhardy alexmog to add an api to find out which element is in
           a named flow
   <trackbot> Created ACTION-350

   vhardy: in css should you be able to set display on grid cell?
   vhardy:  how do we integrate with css grid
   vhardy: one is to have a way to adress a gridcell to make it a region
   vhardy: second, add an element as a child to the grid and declare it a region
   alexmog: it would be interesting to have pseudo elements for other virtual
            things like grid regions for really advanced scenarios.
   alexmog: in pseudo elements you can't get a OM you need an entirely different
            mechanism
   alexmog: it has to be a parallel model.
   szilles: there needs to be a CSSOM module that gives us back the facilities
   RESOLVED: Change the grid to integrate with css regions through regular
             elements

   <bradk> So one HTML element to create a grid slot, and another inside it
           to hold a flow?
   <JohnJansen> correct Brad
   <JohnJansen> (in other words, not do anything special for grid)

   vhardy: if you want to grab content from flow, you use content property
           with from-flow.
   vhardy: there was an alt proposal you should make two properties parallel
           and it should be separate from content use float from and use
           the flow name to get the content from the flow
   vhardy: should we make it through two parallel properties
   vhardy: after we have had more discussions we think this is more clear
           use flow-form: <flow name>
   smfr: would flow-from work on pseudo element before / after
   alexmog: vhardy yes
   dbaron: I am uncomfortable making an additional property here. as it
           seems to do same thing as content.
   * fantasai agrees with dbaron
   alexmog: there are couple of considerations, content has a lot of baggage,
            there is content in css3 content, which is not where the spec is
            going.
   alexmog: the flow-from applies to anything into a region.
   alexmog: the content is somewhat different as it can't seem like it changes
            the nature of what it is applied to
   fantasai: does that mean I can't have a table that accepts content from
            the region?
   alexmog: that is one of the issues, conceptually region is something that
            redirects content from somewhere else into this element.
   fantasai: lets say I have a region and I want it to be a table row and I
             grab the contents of the table row and put it into regions what
             happens
   alexmog: there is nothing in regions that won't work.
   fantasai: so thats not display-inside region you are not overriding display
             inside just putting contents into it.
   vhardy: we have a proposal to limit regions to display-inside block.
   vhardy: otherwise it will become too complicated.
   vhardy: we can resume discussion once we reach that.
   alexmog: I don't feel very strongly about flow-from w.r.t content
   alexmog: content has a history that does not make it designed for this.
   arno: how would flow-from property how would it interact with content
   alexmog: content would be overriden
   vhardy: content is grabbing content from an element but flow-from is
           grabbing a segment not whole element. so it's different
   plinss: thats what you get from from-flow so I don't see why that's a
           problem, you just need to adapt that notion to the content.
   alexmog: from the content property you can figure out what content is,
            from region that is not the same.
   fantasai: having one property that overrides another causes problems with
             cascade
   fantasai: which one wins? we should use the cascade as that's what it is for.
   vhardy: other people felt it was good to add a property.
   alexmog: content applies to inline flow-from doesn't. different compatibility.
            I am not sure it would always be that way. I am not sure if
            flow-from would always override.
   vhardy: content would only apply to before and after in 2.1
   fantasai: in css3 it would apply to all.
   plinss: that has been the plan for 10/11 years at least
   vhardy: the draft has the way you [fantasai] like it
   vhardy: if majority feel we are good with content, I am okay with that.
   alexmog: I don't have really strong feelings.
   alexmog: having seperat property makes writing spec easier. Understanding
            easier. Not redefine content
   RESOLVED: Stick to content property and content: from-flow(<flow-name>)
   <ChrisL> does that mean content can have internal structure, now?
   <ChrisL> or is it flattened text?

   vhardy: currently to put something in flow you use flow: <flow-name>
   vhardy: alexmog pointed out flow could be short hand, so should we use
           flow-into and reserve flow for shorthand
   <dbaron> "rename flow into flow-into" needs to be written down to be
            comprehensible
   smfr: flow-into does not work for me, how about flow-name
   szilles it is doing two things naming and adding content to flow
   smfr: which property is canonical in terms of naming of the flow
   vhardy: the flows get their name from the first piece of content that
           is moved into the flow
   smfr: it is a bit too magic for me
   vhardy: we iterated over that and we ended up settling on this way to do it.
   <glazou> CSS _is_ magic anyway :-)
   smfr: this is more like it is belonging to a flow.
   smfr: make this part of a flow.
   <bradk> I prefer just 'flow:'
   alexmog: we tried things like flow-source and flow-target and those were
            very confusing.
   glazou: we need a resolution to move from flow to something
   szilles: what it actually is flow-out-to rather than into as it is taking
            it out of normal flow
   RESOLVED: change flow to flow-smthing
   vhardy: alexmog asked for renaming from-flow to flow-from
   RESOLVED: rename content: from-flow to content: flow-from
   dbaron: it makes more sense to me the other way
   alexmog: we have border-top-right

   vhardy: auto sizing of regions. this has been called as intrinsic size.
           I am not sure if all the history we have we are using intrinsic
           as a term in our discussions
   vhardy: intrinsic has only been used for replaced content
   fantasai: there is terminology for that in writing modes draft.
   vhardy: I tried to stay clear of intrinsic size coz of possible confusion
   <fantasai> http://www.w3.org/TR/css3-writing-modes/#intrinsic-sizing
   vhardy: if we have auto-sizing in 1 or more dimensions how does it work
   vhardy: we had a discussion with hyatt on mailing list, alexmog brought
           up more questions. this email is a summary of discussions at that
           time
   vhardy: the proposal was do we actually need to say anything about auto-sizing
   vhardy: the main model I have been using for regions, the results should
           be identical if you have broken down regions into bits and pieces
           and moved them into regions
   vhardy: so if I follow that model we don't need something
   dbaron: the problem with that model is that the slicing depends on the size.
   alan: if you have not specified height there wouldnt be any.
   alexmog: paginating content in terms of flexible size is really complicated.
   szilles: the two dimensions inline and block the rules are slightly different.
            in inline you would want it to be like a block, in block
            progression dimension you are going to use breaks to control…
   alexmog: even more complicated is when width is undefined we can come up
            with a width measurement, the final layout is difficult to do if
            you don't know what the width to be.
   alexmog: e.g. for float: right you need to figure out what the size is if
            it should be cleared or not.
   dbaron: whats the proposal?
   vhardy: start with region 1 and then put all content in region 1. if
           anything that does not fit, you have a first segment and reminder
           will flow into next regions. if you have regions with undefined
           height, it just gets all the content.
   vhardy: at any point it would be like rest of the flow will be in the content.
   smfr: say you have a bunch of Ps and a 1000 px wide DIV.
   smfr: the first region is flexible width wise
   smfr: sounds like you would make first region 1000px wide
   dbaron: what is the proposal for what intrinsic size would be?
   dbaron: intrinsic size is not a function of layout
   alexmog: intrinsic is not the right term here.
   <hober> If the intrinsic width of a region is 0, the designer wins because
           their layout "fails fast" & they immediately know they need to
          specify a width
   alan: the proposal is intrinsic size does not apply
   alexmog: we should not be using the word intrinsic here.
   dbaron: I sounds like you are talking about what the sizes of the regions
           are going to be. that is still a separate notion from intrinstic size
   vhardy: intrinsic is used for replaced content 2.1
   dbaron: we used for table,
   dbaron: I am talking about preferred width and min width
   fantasai: we call it two diff things based on if we are on tables chapter
             or not
   szilles: there are two situations, 1. normal flow 2. out of normal flow.
            the rules for width and height calc are diff in those.
   szilles: you use intrinsic when you are out of normal flow and simple calc
            in normal flow
   szilles: regions behave in exact same way.
   alexmog: 3 options:
             1. if region size is undefined it is zero.
                that option works very well the standard box model rules apply
                regardless of where region is.
                the size will be calc using formula for box size.
                problem is when accidentally size is not set on a region it
                has no visibility and it is difficult to understand where it is.
   <hober> that's a feature, not a bug
   alexmog: 2. if it has a specific intrinsic size, 300 by 150 it would be
               useful as you might have forgotten to set a size and then
               you can see it and then make it right size.
               normal box models won't apply.
               and thats not helpful.
   <bradk> maybe we need 'position:flow' or 'position:flow(ident)', and then
           all flows are non-floating blocks.
   alexmog: 3. size to content. we have to figure out what is going to fit
               into this region without exceeding max width max height if
               they are available.
   alexmog: this is very complicated to implement, it would require more than
            1 layout pass
   alexmog: option 4. use normal box model calculations and if that ends up
            as still undefined with height, then use 300x150 intrinsic size.
   vhardy: it is like replaced content right.
   alexmog: it is not like the second option replaced content.
   alexmog: the 4th option would be an implementation of normal box sizing
            where the box size is not considered at the point where it is
            on or not but at the end when it is resolved or not.
   alexmog: I would expect devs to slice area into bunch of rectangles and
            use grid or flex box and then add content to the.
   vhardy: the first proposal, the width and height would be set to 0 if
           you do not set height or width.
   alexmog: this is a strong arg for default size to not be strict width/height
   alexmog: if this region is going to have content in there, it wont have
            a size the flexbox and grid would give it.
   alexmog: for the pruposes of flex or grid it has to have a default size of 0.
   alexmog: then grid would give it size
   rossen: for e.g. auto width should be as wide as containing block so edges
           touch on normal flow. those rules would be ignored as per proposal 1,
           and width would be set to 0.
   rossen: the containers are typically well respected, we don't set to default
           size or width 0. so, which one is it that you are trying to achieve
           here.
   vhardy: the general question is what happens with auto widths and heights
           on regions
   vhardy: the point that smfr made is that if you layout everything then your
           widths may be off.
   vhardy: your use case would naturally work, intrinsic height to default to
           0 it is hard to make it work.
   florian: in general resolving to 0 is something simple but not useful
   mollydotcom: it is established and understood in devs, but now we are
                changing expectation.
   alexmog: 0 is logical, if a region that is part of a chain of regions if
            it does not have any natural content, it creates 0 new rules for
            sizing it.
   alexmog: it is a good default.
   mollydotcom: default to 0 sounds to be very different from what you are saying
   vhardy: I propose we actually table this discussion and go back. the default
           behaviour is not useful, we need to consider usecases.
   phil: I thought it worked with any kind of layout, some proposals sacrifice
         the notion that how the child layout will make use of available space
         given by parent layout
   dbaron: vhardy's statement intrinsic size is 0 then size is 0 is incorrect
   plenty cases otherwise
   dbaron: for intrinsic widths, the obvious solution is to do the intrinsic
           width computation over entire contents of the flow.
   dbaron: what we have not specified we have not specified intrinsic heights
           in block progression dimension. flexbox and this (some degree)
           depends on that concept.
   dbaron: problem: they are a function of width not entirely intrinsic.
           1 concept that is entirely intrinsic and another that is a function
           of width
   dbaron: I can imagine a situation where you want to build heights in
           region by starting either from 1st or last. splitting at breaks
           and using as many regions from beginning or end to build some
           sort of intrinsics where you need them. It might give you useful
           behaviour for a bunch of them
   dbaron: there is a bunch of issues being conflated.
   dbaron: we need a definition for intrinsic sizes and we need to specify
           what actual resolved sizes for regions are.
   szilles I heard you say the cal of size algorithm it does occasionally use
           intrinsic size but not necessarily use intrinsic size. That is
           critical to making it work, and we have a def of intrinsic size.
   alexmog: if whereever in the cal we need the intrinsic size we consider all
            of the content or remainder of content from this to that. that
            makes it clear it might be expensive to calculate. it is really
            a fallback, so not going to be used all the time, so expensive
            should not be a problem there.
   vhardy: that works for me
   ACTION: vhardy Rework the issue of resolved sizes for regions and come
           up with an alt solution for the group along with use cases and examples
   <trackbot> Created ACTION-351

<br type="coffee"/>

   vhardy: region model, so the current spec has taken the approach that
           region is a general relation of an element relates to content
   vhardy: instead of working with children as source of generated boxes
           you would layout, you can get set of elements from source which
           will be used with layout algorithm
   vhardy: looking at use cases, our thinking now is 1. they are like
           printed pages and lay it out from page box to page box. they
           are different viewport areas.
   vhardy: mixing regions that have different type, region thats a table,
           a flex box and put them in a chain does not seem to make sense.
   vhardy: as you would not know which kind of segment you get.
   vhardy: limit regions to apply to things that are display-inside: block
           it could be table-cell or anything that has display-inside: block.
   vhardy: proposal restriction on regions to contain display-inside: block
   fantasai: I can see reasons for display-inside of flexbox.
   dbaron: the current flexbox is different from our implementation.
   fantasai: I can see wanting to have two flexbox containers and have a
             flow between them.
   dbaron: the way flexbox spec works is the container is display: flexbox,
           the items in it is display: block
   vhardy: the idea is to simplify the implementation. not limit the future.
   vhardy: there are usecases for tables as well.
   vhardy: then we have to deal with mixing different float types which are
           much more complicated.
   fantasai: I am okay as long as we can expand it in that direction l
   fantasai: I can see why you would want other display types
   alex: I want to keep the first version of spec simple.
   vhardy: what we are doing is not painting us in a corner. we should have
           a note saying in future we would extend it.
   RESOLVED: for this version we are limiting regions to be block containers
   ACTION: vhardy add a note to expand this in the future for different types
           of containers
   <trackbot> Created ACTION-352

   vhardy: region breaks. CSS 2.1 has page breaks that only work on paged
           media. css3 column breaks and page breaks.
   vhardy:  page breaks slices a column into two, the next column box moves
            to next page.
   vhardy: how do you break content when you layout between regions
   vhardy: those questions also arise for multicol
   vhardy: if you have breaks in ur content and nesting what does it mean for
           heirarchy
   vhardy: current spec: we will add a new type of break and thats what
           content will honor when it lays out content. alex objected to it
           so we came up with alt proposals
   vhardy: instead of saying I need to have a new break, state which breaks
           you will honour
   vhardy: as a region you state which breaks you honor
   vhardy: what that means is content is break aware and container aware.
   vhardy: the content can annotate myself, you can then have container
           types and associated break types.
   alex: is this clear, or do we need a picture
   <bradk> picture
   <ChrisL> picture and photo
   alex: using either column breaks or page breaks producing multicol layout
         with regions there is no way to define currently contents going
         from one column like region to another column like region if you
         have a column break, but if you have a page break then you need to
         go to a new page with a new container
   alex: we need to communicate this region is a column and another region
         is a page.
   <bradk> so, column-break would break to next region if both regions are
           each one-column blocks?
   alex: if we decide we don't need that kind of precise control in regions
         coz that content would be designed in smaller pieces, with one kind
         of break. we would gravitate to never need column/page break
         difference. but only one kind of break.
   <bradk> unless a block is identified as a page somehow?
   vhardy: one of the extensions is to generalise ideas and do named breaks
   vhardy: my content should know what kind of container it is laid out on.
   vhardy: another approach is if your content just wants to know where it
           should break.
   vhardy: second approach content does not know about container types or
           what kind of breaks are being used.
   vhardy: second one is a simplifying assumption and want feedback.
   vhardy: 1. breaks are container agnostic 2. breaks are container aware.
   smfr: there has to be a precedent here? what does page layout do.
   alex: yes, they do different kinds of breaks. page break and section break.
   vhardy: ur q is on existing tools?
   smfr: existing tools
   alex: columns are only possible as full-page columns or full section columns,
         so page break is always a column break. there is no such thing as
         breaking multi-col block …
   alan: in indesign you have a column break, page break, frame-break
   alex: whats the diff between frame/page break
   alan: frame break is like a region
   florian: can you have nested frames
   <bradk> frame breaks can jump across several pages to get to next frame
           to, right?
   alan: I think so, I do not know if it makes a difference in the break
         scenario.
   vhardy: frames are more like regions
   alan: yes
   plinss: don't confuse column breaks with region breaks as column only
           breaks to another col not a region
   plinss: I don't see why you should respect other kinds of break.
   alex: so how do you know the region is in the next page?
   plinss: from the pagination model.
   alex: what is a page?
   fantasai: a page in css is a "page box"
   fantasai: in mozilla we have page boxes as a particular kind of css box
   alex: in IE they are also kind of a box.
   fantasai: a page break requests a break between page boxes.
   alex: I would like to be able to write page view in a standard way not
         just for print preview but also for page reading (like online magazine)
   plinss: if you are doing with divs you are not doing anything with css
           page box model.
   alex: you can have multiple regions in every page. if you are going to do
         page break in content and requires it continue to next page, no
         way to determine what next page is.
   florian: you need something that gets you to next page
   florian: if we want to support that we need something like that.
   alex: if some content that you place in to region has page-break: avoid,
         is that something regions will not be capable of satisfying, or
         would we have something different.
   <fantasai> break-before: region(mycustompaginator)
   smfr: why don't you use normal paged media?
   alex: if nothing more advanced is available we would consider every region
         is a page from point of view of breaking
   szilles: all the things you have said requires a content change.
   szilles: the author wants to present this content if it were a page in the
            display he is presenting to the user
   vhardy: if you want something foo, then you say break for 'foo'
   alex: I don't get why you are objecting. moz has internally a special
         element to represent …
   fantasai: No, we have something in the rendering tree that represents a
             page box. It's not an element.
   alex: as an author how do you make an element a page box
   fantasai: You can't.
   alex: with regions we are creating an opportunity for author to use page
         navigating algorithm.
   plinss: do you want headers and footers to appear on random elements?
   dbaron: there is an assumption that you should be able to do what you
           described without changing the content. I don't think that's true
   florian: you might want to break sometimes on certain page breaks and not
            on some others.
   vhardy: the the intended functionality is to have more than 1 kind of
           break
   <bradk> What about regions inside regions inside regions inside regions?
           You need to be able to indicate level
   plinss: you really are talking about a region break to a higher level
           (in nested regions).
   fantasai: e.g. break-before: region('named flow');
   <bradk> You might not know the region you are in, but know that you want
           to break 2 levels up. break-before:region(-2)
   vhardy: take an action to add the use case alex is talking about and measure
           up the actions
   alex: only region break is also generally okay.
   alan: before we got to pagination, it sounded like plinss was saying if
         we have col breaks and region breaks and I have flow going to regions
         that are not going to multicol elements you would prefer col break
         to not break to next region.
   vhardy: if you got page break and not in paged media it does nothing
   alan: if you have a region situation and you have a column break I prefer
          my text to go to next region from auth perspective each region is
          a single column
   alan: we have usecases where regions to use multicol layout
   alex: in multicol spec does it say in paged media each page should be
         considered a column?
   ACTION: howcome to answer if paged media each page should be considered
                   a column?
   <trackbot> Created ACTION-353
   vhardy: option1 seems to be off the table.
   vhardy: we agree we need breaks that are typed.
   plinss: if we have nested region flows we need ability to break a level.
   plinss: the types of usecases that alex is taking about I think we should
           have to work on getting browsers to render a page in paginated mode.
   <fantasai> There was a suggestion to add 'overflow-style: paged' a while ago.
   <hober> Yes, some kind of explicit "I want paginated mode" switch is much
           cleaner
   <bradk> or a section of a page in paginated mode
   alex: we are making it possible to create a webpage that gives you the same
         experience as looking at a magazine. give it same kind of control
         including control of column breaks and page breaks. we would need to
         create new break types
   alex: if we switch browser to switch to page mode, the ui browser provides
         to navigate pages is light years away from what designers would want
         in page navigation experience
   RESOLVED: we need breaks that are specific to containers they are part of.
   ACTION: vhardy come up with a proposal for breaks either a page-break or
           a general type of break or both and related use cases
   <trackbot> Created ACTION-354

   smfr: we are not happy with behavior for iframe objects in spec
   smfr: issue 5
   <hober> http://dev.w3.org/csswg/css3-regions/#the-flow-property
   alex: it is not an issue any more. I added it in.
   <hober> "For an <iframe>, an <object> or a <embed> element, the ‘flow’
           property has a different behavior. The effect is similar to
           turning the ‘display’ property on the element to ‘none’ while
           moving the root element of the referenced document to the named
           flow."
   alex: if we remove it, then it would be a non-standard thing like
         font-size-adjust. if it stays there, it is okay to have it optional.
         Another option there is to have an explicit way of saying for an
         element if the element that is added to flow or content added to flow.
   alex: I like the second option as it is much more explicit.
   smfr: you start introducing cross origin problems also q of what to do
         with script style elements and stuff
   alex: the cross frame security does apply. We are not going to take content
         from iframe if its not in the same origin.
   smfr: the spec should say that.
   dbaron: sounds a lot like seamless iframe stuff html5
   dbaron: should we do that instead of redefining it
   TabAtkins: seamless iframe becomes like an included
   anne: the iframe height becomes height / width of the document. selectors
         bleed through.
   alex: no default padding
   <dbaron> http://dev.w3.org/html5/spec/the-iframe-element.html#attr-iframe-seamless
   <hober> So in a region <iframe> would behave like replaced but
           <iframe seamless> would behave like alex has specced
   ACTION: alexmog to look at seamless iframes and reconcile it with what
           we have in the spec. We should add the security consideration
           into iframe paragraph.
   <trackbot> Created ACTION-355

CSS Floats and Exclusions
-------------------------

   vhardy: we have had diff proposals for floats and exclusions
   vhardy: worked on a bunch of use cases.
   <bradk> link?
   <stearns> http://wiki.csswg.org/ideas/css3-floats-use-cases
   <bradk> thanks
   vhardy: we have a model we would like to propose to the group
   vhardy: present this to be ready for editors draft that is a convergence
           of these two proposals.
   rossen: 2,3,4 are essence of how we build the model and 1 is how we use it
   <smfr> http://wiki.csswg.org/ideas/css3-floats
   rossen: how to create container model.
   rossen: #3 how the shape gets affected by exclusion
   rossen: in our case, we looked at a diff point of view, already have
           exclusions in css2 which are floats
   rossen: overloading the float property was redundant. we still had to
           use wrap-mode in ms proposal to trigger an exclusion
   rossen: in our case the wrap-type was defaulting to around. so it was
           enough to say float: position to create an exclusion but in
           reality it needs both
   <RRSAgent> See http://www.w3.org/2011/07/25-css-irc#T19-01-34
   rossen: agreement is wrap-mode should be enough to create an exclusion
           as reg floats are already exclusions, we don't need another.
   rossen: it would be interesting to combine what wrap mode really means
           outside or inside of shape
   rossen: if you want table cell circular, you can apply shape on the inside
           of an element without affecting the outside default shape/box model
   rossen: the last version of proposal we had, wrap-mode: default as if
           wrapping was not involved.
   vhardy: this is a stub, I need more work on that.
   alex: so initial is around?
   rossen: initial is none
   szilles: if its auto floats can behave the way they do today
   vhardy: I propose we don't get into this. we need to work out the details.
           we have not discussed it.
   rossen: thats fine by me
   dbaron: I am uncomfortable about making resolutions about details when I
           do not understand the models yet

   vhardy: wrap-mode: inside it will wrap inside (shows slides)
   vhardy: wrap-mode: all-left would control the wrapping internally for
           the left side.
   vhardy: we resolved having 1 property trigger an exclusion rather than
           2 proposed by ms
   alex: maybe we don't need resolutions on these fine grained issues.
   vhardy: I think the resolution is to have a single trigger than 2.
   vhardy: not on the specific properties
   dbaron: it seems like you are proposing the model where anything wraps
           around anything. I have not seen a lot to explain how that's
           supposed to work. I saw the spec which says this syntax is
           supposed to do this thing but it is no where close to doing
           that thing.
   vhardy: we will get to that.
   ACTION: vhardy make the default value for wrap-mode be auto.
   <trackbot> Created ACTION-356

   rossen: next point is containing model for exclusions
   rossen: we didn't make any change to css to containing model. based on
           position property containing block is computed just like css2 block.
   rossen: there is one exception, that is the new position: page value that
           we are adding
   arronei: we can talk about that later when we get to css position
   alex: what it is saying is that the scope of what an exclusion affects its
         containing block.
   alex: the important difference this makes compared to other containing
         model is that it could be defined an element affects anything that
         it visually overlaps.
   alex: it could be defined an element with exclusion affects an element
         further down in the content flow and nothing before it.
   alex: that would be very limiting in positioning exclusions backwards
         and forward which is a very common use case
   dbaron: so you are proposing that things that create exclusions are still
           positioned according to normal css rules
   dbaron: 2 divs both contain text, the second div has margin-top: −5em
           wrap shape smthing to make a circle that is 5em radius and they
           both have text.
   dbaron: where do you position the second text?
   alex: we are getting there to describe the processing model which is
         where we resolve contradictory layout situation.

   alex: can we go over issue 5 then issue 1 as issue 1 is most difficult issue
   rossen: so, issue 5 was ordering of exclusions. both the container
           models is same as css2.
   rossen: everything in the scope of the container will be affected by exclusion
   rossen: overlapping exclusions:
           1. first draft mentioned taking doc order which was not intuitive
           2. we are staying with z-index ordering.
           that appeared as double dependency from exclusions from within the
           content that would influence the outer exclusions or content outside.
           but we are scoping the effect of exclusions to containing block then
           ordering per z-index becomes much more easier.
   szilles: show the example.
   rossen: it is visual vs. content order by default.
   alex: based on z-index, if its not set, elements that overlap prev elements
         then later elements create exclusions over prev elements. we should
         try to avoid relayout.

   dbaron: so when you say exclusions affect only other things in containing
           block I presume you mean everything descendant from containing block.
           It includes siblings and so on
   dbaron: this idea of using z-index you are potentially crossing stacking
           context
   dbaron: with subtree model, you can be in situations where excl A should
           affect B but not vice versa as A is a descendant of B's containing
           block but B is not a descendant of A's containing block.
   rossen: if you are on some level of the tree, and you have containing block
           which have exclusions on each side. and a set of eclusions coming
           from its container.
   rossen: you can order the exclusions in the containing block. you can only
           take exclusions that are higher than your z-index. once you take
           those exclusions in your container then you need to resolve with
           exclusions inside.
   rossen: even if you resolve the exclusions inside, it does not affect
           exclusions that are coming above the containing block.
   phil: you have a positioned element, and it has some negative z-index so
         it's going to be behind rest of the content.
   <dbaron> just trying to figure out if this z-order model makes sense given that

   alexmog goes to the board to draw
   <mollydotcom> here's a drawing http://twitpic.com/5vs3ra
   rossen: it may or may not wrap around D depending on z-index
   rossen: we know D can never wrap around C
   vhardy: is D a containing block?
   alex: all are abs pos
   rossen: the answer here is we apply priority based on z-order at container
           levels
   rossen: if something affects B based on z then everything in B would be
            affected by that.
   rossen: there should be no way D would wrap around C, so there is no way C
           would wrap around D.
   phil: what if there is opacity on D?
   alex: D does not have to use wrap-mode it does not have to create an exclusion.
   rossen: exclusion is only when you want to "exclude"
   alex: discussion on using z-index or other kind of index is a separate discussion.
   alex: issue is to determine order on exclusions and we have come up with
         z-index.
   rossen: the prev containing model was different that was exposing a number
           of complexities
   alex: we should consider all the complicated z-index combination and see
         if it works
   szilles: what you saying is that the drawing order is the model of exclusions
   szilles: z-index affects the drawing order.
   glazou: we will continue after lunch

ScribeNick: TabAtkins
   rossen: [something about z-order] Did that make sense to everybody?
   vhardy: We'll just take all the feedback and integrate it into the next draft.
   rossen: Back to issue 1, processing model.
   rossen: Currently we take the easy way out.
   rossen: We treat exclusions as out-of-flow, so you lay out once to pick up
           any "auto" positions that exlusions may anchor to, then you position
           exclusions, then you fill in the rest.
   rossen: The obvious problem with this is the accumulation of error;
           exclusions will push around their own or other's auto positions.
   rossen: There are discussions about a better processing model that would
           keep the auto positions closer to the right place in the flow,
           but so far there's been nothing solid enough for us to write down.
   rossen: That is the processing model we have for oof with
           position:absolute|fixed|page.
   alexmog: The model rossen is describing, I'm proposing to have it as
            non-normative atm; it describes something specific enough that
            simple cases can be interop, but it leaves room for a more
            advanced processing model later.
   alexmog: We'll tighten it up as we get impl experience.
   arronei: If you make it non-normative, you can't test it or depend on it.
   alexmog: We can make it normative to the extent of the simple bits, but I
            don't think we can fully fill it in yet.
   rossen: position:static has only one difference - you actually lay out
           with the flow.
   rossen: For position:static exclusions, they're laid out with the normal
           flow pass.
   rossen: If all you have is static exclusions, you don't need a second pass,
           as they're laid out as part of the content.
   alexmog: What happens if they have a negative margin?
   rossen: Same as today - they'll overlap the previous content.
   alexmog: Doesn't that contradict what exclusions should be doing?
   <bradk> It would be like a float, more or less, if static? Only affecting
           the leading edges?
   <TabAtkins> bradk, yeah.  Just a shaped float.
   rossen: They only push around other stuff in the abspos case.
   rossen: [draws a diagram]
   <bradk> Can someone post a photo once there is something to look at on the
           whiteboard?
   rossen: While laying out text, you lay out line by line.  When you encounter
           a static exclusion, you're in the middle of layout out one line
           (previous lines are already done).
   rossen: If this was a regular div, the block would consume all the space to
           its sides, pushing following text below it.  Exclusion just lets
           following text fill in space around it.
   rossen: Moving on to further issues.
   <mollydotcom> here's a photo of the diagram when encountering static exlusion
                 http://www.twitpic.com/5vt57v

   rossen: issue 7, what does "shrink-to-fit" mean for floats with shapes?
   rossen: We defined an easy way out here - use the bounding box of the
           exclusion shape as the "shrink-to-fit" for the floater.
   alexmog: Nobody really liked the idea that they have to calculate the
            closest intersection of arbitrary shapes - too hard of a problem.
   alexmog: So it should be acceptable to treat exclusions as rectangles for
            the purpose of shrink-to-fit.
   alexmog: [something explaining the above point that I missed]
   rossen: I think the shape doesn't correspond to the border box - it could
           maybe define its own bounding rect.
   alexmog: It shouldn't get bigger than what's calculated with bounding boxes.
   alexmog: You can always make it smaller.
   szilles: I'm slightly confused.  If I have a wrap-shape, it has a size.
            Why do I need shrinkwrap at all?
   rossen: We're talking about floats that are themselves shaped.
   dbaron: The shapes can have percenetages, so the shape is based on the
           size itself.
   dbaron: If the shape is a circle centered on the box with a radius of 50%,
           the shape is a function of the size.
   rossen: If that was a div with width:50% inside of the float, the same
           effect would occur.

   rossen: One more difference from the original exclusions spec was a property
           named "flow-wrap" that allowed elements to not pay attention to
           exclusions.
   rossen: We should maybe rename it.
   rossen: A lot of people thought it was related to a "wrap-mode" property.
   rossen: We also have Daniel's proposal that proposed a fairly different way
           to introduce exclusions.
   vhardy: I think your presentation is a convergence of the two proposals.
   rossen: Yeah, it got assimilated.
   vhardy: So I think the next thing is to work on a new ED.
   arno: And that's a wrap.
    /groan
   <stearns> perhaps the name for "ignore wrap" should follow whatever we end
             up with for "cancel-underline"

   alexmog: I think we came to the conclusion that the name of the module
            should be "CSS3 Floats".
   alexmog: It eventually needs to be a bigger doc that describes much more of
            the processing model, describing floats that don't overlap too.
   alexmog: [something about how extending 'float' might work]
   arno: Would that be in CSS3 Floats or something else?
   vhardy: I think we should produce a first draft that covers what we know
           we want and have.
   vhardy: Then later figure out how we want to slice it with gcpm and other
           float-related things.
   arno: My concern is that if this is float-related, we'd have to close on
         everything float-related to make this work.
   alexmog: I had the same concern.  I think we can do Exclusions separately
            from Floats.
   alexmog: there is an issue with making Exclusions a Rec without having
            anything with floats.
   alexmog: But I think vincent has the right idea that we should write the
            draft now, and when we see it, it should be easy to tell what
            the right name is.
   dbaron: My general feeling about this draft is that it's very complicated
           to implement, and it's possible to write something much simpler
           to implement with most of the functionality.
   dbaron: I may want to look into going that way, but I haven't had a chance
           to do that yet.
   vhardy: If we produced a new draft that you could comment on, would that
           be ok?
   dbaron: I think at this point the best way forward for me is to produce
           a new proposal.
   florian: If we have proposals that look close enough, it's worth merging
            them. But we're early enough on right now that if there's something
            significantly different, it's worth exploring that separately.
   alexmog: I would be really glad if we could remove things from the draft
            and still meet the goals.
   florian: David, is what you have in mind the current draft with some things
            removed, or something totally different?
   dbaron: Similar things, but with a significantly different processing model.
   dbaron: I'm thinking that I want to separate the reordering aspects, and
           then not have the reordering implications within layout.
   dbaron: So if you need reordering, that's a separate process, and then
           layout is still one pass.
   dbaron: The part of this draft that scares me is the part that's not yet
           written.
   dbaron: It's hard to know I have comments on it before I read it. There may
           be a big gap somewhere that implies a big complicated chunk of
           processing model.
   dbaron: I've only thought about it for the last few days.
   vhardy: The processing model we've described is a bit different than what's
           currently in the ED.
   dbaron: I couldn't find much of a processing model.
   florian: Do you think that what you want fits within the shape of the
            existing proposal?
   dbaron: There are some examples that I know don't fit, but they're
           incomplete examples right now.
   rossen: Have you checked out the wiki examples yet?
   dbaron: Not yet.
   <smfr> http://wiki.csswg.org/ideas/css3-floats-use-cases
   <arronei> http://wiki.csswg.org/ideas/css3-floats
   rossen: If you could look, it would be great to have a review and see what's
           missing or what's overcomplicated.
   rossen: If you have an alternate proposal, I'd like to see if it solves
           these use-cases.
   vhardy: We should take an action item to review this page.

Writing Modes
-------------

   <glazou> jdaggett: can you hear us?
   fantasai: I think there are several issues open right now.
   fantasai: One is the name of the property.
   fantasai: Second is the default orientation at a codepoint level.
   fantasai: The third is whether we're doing context-based resolution of
             punctuation, and if so, how?
   fantasai: The fourth is if we're giving additional controls at level 3
             (beyond what you can currently do with text-orientation).
   jdaggett: Let's start with sylvain's issue.
   jdaggett: I think #3 and #4 are dependent on a concrete proposal for #2.

   szilles: Two more issues are Nat's comments on TCY
   szilles: I think you suggested separating the text-combine prop into one
            that did manual TCY and one that set up automatic TCY.
   szilles: They may want to be over different ranges.
   jdaggett: Why do you need that distinction, Nat?
   <dbaron> (TCY == Tate-chu-yoku)
   nat: Right now we have text-combine:horizontal, then a bunch of values
        for controlling the auto case, I guess.
   nat: Is that what we want?  Just specify it on, and then specify the
        details (do letters, do digits, combine X many)
   nat: And then, if the letters in the span meet that criteria, combine them?
   florian: One case was that, or a date, you don't wnat to have to add extra
            spans around the day and month and year, but rather just one around
            the year.
   nat: The other issue I had was the defualt implied value.
   fantasai: The values are "none", "all" (tcy the whole span), and then
             various options that control what things are combined.
   <jdaggett> nat's post: http://lists.w3.org/Archives/Public/www-style/2011Jul/0405.html
   <dbaron> http://dev.w3.org/csswg/css3-writing-modes/#text-combine
   nat: I thought if I tried to implement this, it would be easier if I didn't
        thave to worry about having a state machine go through the text.
   fantasai: You can't combine, say "all" and "latin 4" - it's not syntactically
             valid.
   nat: I think some examples would help here.
   nat: So when it's not all, you can do auto TCY in any span.
   <fantasai> ACTION fantasai: Add syntax examples
   <trackbot> Created ACTION-357

   nat: A second point, why do you have, in the alphanumeric tolerance section,
        a "1.1em" figure.  That seems arbitrary.
   fantasai: koji was talking with hyatt about that issue.  Hiragino apparently,
             if you ask for half-width glyphs, won't fit within 1em if you put
             them side-by-side.
   szilles: if that's true, why not just do it when they ask for it?
   fantasai: This is for whether you scale or not.  This number is close
             enough that you usually won't have to scale.
   kojiishi: The idea of scale is to compress glyphs so that they fit into 1em.
   kojiishi: But there are some fonts that get slightly gretaer than 1em when
             you set two half-width next to each other.
   kojiishi: So if two chars are much larger than 1em, authors would likely
             want to compress them.  But if they're just a tiny bit over
             (maybe accidentally, like described here), you'd want to just
             leave them alone.
   nat: Okay.  I think having the built-in tolerance is orthogonal to the
        scaling issue.
   nat: If you're tolerant of the idea that you're using glyphs that dodn't
        fit into 1em, you're probably okay with not scaling, so you should
        just say no scaling.
   kojiishi: Even if you do scale, though, you probably still don't want to
             scale if you're just very slightly over 1em.
   nat: But you're saying to scale it to 1.1em, not 1em.
   nat: You can have an "auto-scale" that has some tolerance in there.
   florian: Can we just have a scale with no tolerance, and let you add the
            tolerance in specifically?
   szilles: If they're images, you really notice the artifacts.  If they're
            outlines you won't notice as much.
   szilles: Can we say something other than "scale"?
   squish/compress/scale-x?
   <bradk> condense, horizontal scaling
   Nat: condensed is bad because it implies a different font selection
   fantasai: compress
   jdaggett: If someone wants this tolerance, they should be involved in the
             discussion.
   florian: I don't think it's useless, but it seems to be going a bit too
            far right now.  Push it to level 4.

   fantasai: The tolerance is used in the scaling (removed now), and also in
             the "used glyphs" section.
   fantasai: Which says to use half/third-width glyphs if available; if not
             available, scale.
   <bradk> Adobe calls it "horizontal scaling" in their programs, IIRC, FWIW
   fantasai: What might happen is that you say you want to use third-width
             glyphs, but it ends up being rendered with a font without
             third-width glyphs.
   fantasai: The default action, then, should be to go ahead and scale, as
             that's minimally invasive to the rest of the page design.
   nat: Is that how it's supposed to work?  I didn't get the idea that things
        had fallback.
   fantasai: You can combine "scale" and "use-glyphs".
   szilles: Why wouldn't you scale to 1em?
   florian: You'd scale to 1em, but you wouldn't scale if you're "close enough"
            to 1em.
   szilles: [an example with "1.3" and TCY]
   <bradk> Is it tragic to allow the glyphs to overflow if they are slightly
           too wide?
   jdaggett: In the original document this was based, there's an example for
             that.
   <jdaggett> original document == jis 4051 spec
   szilles: I know that stuff like TCY'd "1.357" is actually done.
   nat: I think we should just have a "use glyphs" option, and if glyphs don't
        exist, just do fallback.
   fantasai: We can say that if you find the right glyphs, just don't worry
             about compressing.  Assume that the glyphs are the right width.
   kojiishi: If the first font has the glyphs (slightly off the right width)
             but the second font doesn't, the first font would grab the glyphs
             and be slightly off-width, while the second would synthesize and
             be exactly right.
   nat: I think you're far off in edge-cases here.
   szilles: I think it's pretty simple.  If it has half-width glyphs, it has
            half-width glyphs.  Just use them.
   nat: Why are we doing anything if the half-width glyphs don't exist?
   szilles: CSS generally tries to best capture the authors' intent.
   kojiishi: If the author says "digits 3", and the half-widths are slightly
             more than half an em, you'll get slightly more than 1em-width TCY.
   fantasai: Is it possible to know if the font has third-width glyphs?
   nat: There's a feature in OT that the UA can query.
   jdaggett: The problem with these features is that for different features,
             different sets of glyphs are available.
   jdaggett: For third/fourth-width, often only digits are available.
   szilles: What about numeric punctuation (periods and commas)?
   nat: Generally not.  Most only have half-width punctuation.
   szilles: So you could do years and integers, but not decimal numbers.
   nat: Right.
   szilles: I think we just need a clear processing model of when things
            are decided.
   szilles: I don't think we want to say "let's make as tring, and then try
            to compress it".  I think you want to first check for half-width
            glyphs or whatever, and then build out of what exists.
   szilles: So I want a clear statement of what you're looking for from the
            font, and under what conditions.
   fantasai: So what I'm hearing is that we should use the correct glyphs if
             the font has them, otherwise synthesize.
   fantasai: So if I'm doing "122", if the font has third-width glyphs, I
             use them.  If it doesn't, I scale the "1" and "2" glyphs and
             then combine them, rather than making "122" and then scaling.
   florian: Also, the current spec specifies just that they should fit into
            1em, which allows cherry-picking half and quarter-width glyphs
            and combining them, which is not what you want.
   <bradk> Doesn't kerning and tracking affect if two 1/2-width glyphs fit
           into one em?
   fantasai: We can tell if the font has a "third-width" feature, but we
             don't know if individual characters have third-width glyphs.
             So if I wanted "IBM" in third-width glyphs, I'd request those
             glyphs from the font as third-width glyphs, but I may or may
             not actually get third-width glyphs back.
   fantasai: So once I get them back, if they're wider than 1/3em, I need
             to scaled them to 1/3 em.
   fantasai: I think we can make an exception that, for half-width glyphs,
             don't measure and just use what you get.  You may get proportional,
             which may be close enough.
   bradk: Can kerning affect this?
   nat: You don't kern monospace CJK fonts.
   jdaggett: In theory, it's an issue; in practice, you don't ever kern these
             types of fonts.  I don't think we need to worry about it.
   <jdaggett> ... you don't generally kern these *glyphs*
   <jdaggett> i.e. third-width glyphs
   kojiishi: I think it may still be useful to have an option to not scale
             glyphs, as it may be ugly sometimes.
   florian: Perhaps if you say "use-glyph no-scale", you just use exactly
            what's given back by the font, no measurement.  It may be too
            big, but shrug.  Then "use-glyph" will scale if they're too big,
            and "compress" will just always scale the full-size.
   fantasai: Makes sense.
   <fantasai> ACTION fantasai: edit as above
   <trackbot> Created ACTION-358
   RESOLVED: Remove the concept of glyph-size tolerance from this level of
             the spec.
   <jdaggett> whatever you spec out, you need to try it on some simple
              examples and include them in the description
   <jdaggett> the markup should be easy and the implementation should be
              fairly easy
   nat: yeah, you don't want multiple passes to support TCY

   fantasai: So for fonts with propotional, but not half-width glyphs, if
             you say "use-glyphs", should we just use the glyphs directly?
   szilles: I think, since the user can say "no-scale" if they really don't
            want it, you should have a single default that works decently
            enough for everyone.
   kojiishi: The tolerance came in to address the common case where the TCY
             want to use two digits without scaling.
   nat: If we have different scaling values (depending on number of digits),
        it's too complicated for the value you get.
   nat: I agree that it may be useful in some cases, as Koji says, but I
        don't think it's worthwhile to address.
   nat: Koji brings up the possibility that some people may want to scale
        only when it looks terrible, and let it not scale if it's "almost
        there".
   nat: But I don't think it's worth dealing with that explicitly. That
        should be something a UA could decide.
   florian: Or we could go with steve's idea of adding a parameter to
            no-compress, rather than using tolerances
   szilles: I mainly just think we're spending too much time on this.
   fantasai: And the default is the UA tries to do whatever it can to make
             things fit.  No limitations.

   nat: Moving on, it looks like you can omit the integer in "digits" etc.
        and it defaults to 2.  I think it would be better to be explicit.
   fantasai: Okay.
   kojiishi: You're not requiring an integer for "all", right?
   fantasai: Right.
   nat: We should just make "all" be very simple.  It does *all*.
   <szilles> Add Usecases for 2 or 3 digits in auto t-c-y and have an example
             with mix of digits and non-digits; e.g., "1.2"

   fantasai: If you say "use-glyphs" and there's only a single char, the
             current spec says to use a full-width glyph if one is availab.e
   nat: And I think you shouldn't do that.
   nat: glyphs substituation may cause problems (undefined?)
   nat: Are you supposed to scale up the glyphs to 1em, or what?
   fantasai: I'd just use proportional

   florian: I think we've said that TCY and text-transform interacts.
   fantasai: Spec says that any text-transform features are turned off for
             combined text of more than 1 char.
   florian: Then that's fine.  You can use text-transform to get single
            large chars, but have smaller chars for more TCY.

   fantasai: jdaggett you were saying that for text-orientation we should
             write up proposals first and then discuss?
   jdaggett: Yeah, I did some experiments.  Spec says currently that you have
             to use the VR2 feature of the font, but in practice that doesn't
             really work.
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Jul/0401.html
   jdaggett: In the post I summed up the key points:
   jdaggett: Latin will rotate, greek and cyrillic won't, and there are many
             other cases where it's not clear that what exists is what you want.
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Jul/0402.html
   jdaggett: In discussion with Erik Muller, we thought it made more sense to
             specify a property (possibly going into unicode) that says whether
             a character is upright or rotated.
   jdaggett: Then we can use that property to define the gray areas here.
   jdaggett: symbols, punctuation, currency, etc.
   fantasai: That sounds reasonable.
   jdaggett: I just don't think this can be a derived property from the
             existing values.
   fantasai: Agreed - but until it's a unicode property, we'll have to have it
             be derived with a large list of exceptions.
   jdaggett: And then the logic of text-orientation will be to use that
             property, then apply the "vert" opentype feature to the upright
             runs.
   nat: And you do that so fonts which disagree with the feature can achieve
        that?
   jdaggett: Yes.
   nat: I'm comfortable with that.
   jdaggett: This property effectively already exists, but it's just custom
             right now in different tables.
   jdaggett: IE already has it (though clearly out of date; it doesn't do
             non-BMP). Webkit has a similar table, similarly wrong.
   <ChrisL> has Unicode consortium been asked to add this property?
   jdaggett: It would be great to pull together our individual dbs and help
             make a proposal to unicode.
   nat: InDesign has something similar too.
   <ChrisL> (I take what jdagett said to mean "not yet but we will")
   <TabAtkins> chrisl, I believe so, yes.
   jdaggett: I don't think we need to get into the individual heuristics yet.
   nat: When unicode didn't provide two codepoints for something that was
        two codepoints in shift_jis, we have to be able to differentiate.
   nat: Some fonts have different designs for the two.  In some fonts you
        want to rotate, and in others you don't.
   fantasai: We can get info for Japanese fairly easily, but I'm concerned
             about other languages like Chinese where we don't have much
             if any information.
   nat: It's different, and unfortuantely the standards are even more loose.
   nat: We don't use font metrics, but it's very complicated to deal with this.
   jdaggett: to handle that sort of thing, we could call out those specific
             codepoints and deal with those in a separate category.
   jdaggett: So CSS3 can deal with japanese well, but the separation lets
             us make better rules for Chinese and such later.
   szilles: You and I, jdaggett, have proposed being able to provide a delta
            on the unicode table.
   jdaggett: I think it would be better to wait and propose the property
             first, then went through and discussed how you might want to
             modify it.
   szilles: Right; I brought it up as a reminder of the concept.
   jdaggett: Right. it would be nice to eventually let authors say exactly
             what defaults they want ("never rotate english text"), so they
             didn't need to put a bunch of markup around specific areas.
   szilles: It would also allow all the default tables out there to be
            incorporated.

   fantasai: I have a concern that the rest of the draft (the layout parts)
             really ought to be stabilized somehow.
   fantasai: We have a lot of work left to do on text-orientation, but I
             think the layout bits should be locked down and not held back
             by this work.
   fantasai: Another month or two I can handle, but if this'll take us until
             next year, I'm concerned.
   jdaggett: I don't think it'll take that long.

   fantasai: One more item now.
   fantasai: Sylvain was talking about the name of 'writing-mode' property.
   sylvaing: The writing-mode property says it defines block-progression
             (then why isn't in named "block-progression").
   sylvaing: then it says that the writing mode is deifned by three properties,
             one of which is called "writing-mode", which is confusing.
   fantasai: I think we shouldn't change the name, but if you have a better
             term...
   sylvaing: There used to be a block-progression property.
   fantasai: Yes, because at the time writing-mode was a shorthand that
             overrides "direction", which was a very bad thing. We've
             had this discussion a few times.
   fantasai: And it's incompatible with SVG and IE6.
   sylvaing: What is?
   fantasai: We could call it block-progression, but then writing-mode would
             be an alias.
   dbaron: Is this a naming discussion, or a substantive one?
   fantasai: Kinda both.  Given legacy and other reasons, I think the name
             should stay, but I'm willing to change the terminology.
   szilles: I agree that this would be better called "block-progression".
            But history/SVG means that it should stay consistent and be
            "writing-mode".
   <ChrisL> svg also uses the term 'block progression direction' (from xsl) btw
   fantasai: I'd just like to avoid property aliases.
   <ChrisL> but it does use the writing-mode property, yes
   * jdaggett egads
   dbaron: value aliases are much easier than property aliases.

<br/>

Gradients
---------
Scribe: fantasai

   Tab: 3 issues to resolve
   Tab: First one is repeating gradients when the distance between the first
        and last stop approaches zero
   TabAtkins: zw gradients are not a problem without repeating, but is a
              problem for repeating because you can't repeat them on the
              same point infinitely
   TabAtkins: Right now I punt on the issue by making repeating gradients
              required to have minimum 1px width
   TabAtkins: That guarantees we can tile the space like we should
   TabAtkins: Don't know if it's ideal, but it stops the problem of infinity
   * glazou loves when Tab explains that n * 0 is always 0 whatever is n :-)
   TabAtkins: Other possibility that preserves continuity is that when we
              hit zero width, we pick the average color you'd get
   * glazou loves when Tab explains that infinity / n is always infinity
            whatever is n :-D
   TabAtkins: Seems kinda complicated for an edge case, but I don't realy
              care, just want a decision
   TabAtkins: And to be consistent with svg
   Florian: Pixels aren't px
   TabAtkins: I'm fine with saying it's a hairline wide
   Florian: So you do fallback at device pixel
   Brian: WD says to use first color stop
   TabAtkins: Yeah, but that's not continuous behavior
   <ChrisL> device pixels is better. because svg scaling can mean that a 1px
            is really big
   [fast talking]
   Brian: Non-repeating radial gradients folow last color stop rule
   dbaron: But with those you always fill the area outside with that color
   TabAtkins: As you approach the limit, you get that result
   Brian: So it's continuity issue.
   TabAtkins: I'm ok with either way, whatever way implementers would like to
              do, let's do
   shepazu: SVG, when it hits zero, says that nothing is rendered
   shepazu: That kinda punts on that
   shepazu: I don't know that SVG says anything about approaching zero
   <ChrisL> it does not, no. its either a zero bounding box or it isn't
   shepazu: The averaging thing doesn't seem like what ppl want to do
   fantasai: I think that makes the most sense; as you zoom out that's what
             you'd get
   shepazu: It'd be mixed with other color.. start color end color harmonious
            with page
   TabAtkins: If you do 1px red blue and repeat it, it looks purple. If you
              make it smaller, can assume it'll look purple
   Brian: 1px seems too large to me. But making the spec normative at 1px,
          but allow better resolution
   TabAtkins: So the clamp is at 1px or below.
   <ChrisL> px or device pixel?
   <fantasai> CSSpx
   <ChrisL> eww
   Florian: So this would allow them to go to device pixel, but not force it
   <ChrisL> device pixels is better. because svg scaling can mean that a 1px is really big
   Brian: Do you want inconsistent rendering across zoom
   Brian: If you'll get purple pixels sooner at one zoom level than another
          zoom level
   ...
   * glazou waited for "infinity * 0 is undefined", here we are :-)
   TabAtkins: Gradients are a vector format in any case
   shepazu: If you zoom in until 1px is the whole screen, then what?
   TabAtkins: You're allowed to clamp at a smaller size
   Brad: Makes sense. Like with text you get better resolution as you zoom in.
   TabAtkins: It ends up being a quality-of-implementation issue.
   dbaron: You could just specify that as the length of the repeating gradient
           approaches zero, you should average the color.
   Florian: Need to make sure it's not going to do that at 20px
   <ChrisL> <g transform="scale(1000,1000)"><rect width="1px" height="1px"
                                                  fill="url(#gradient)"/></g>
   <ChrisL> I don't want the 1000 by 1000 device pixels rect above to be a
            solid colour
   plinss talks about billionths of a CSSpx
   dbaron: I think it should be device pixels, because if you zoom out ...
   plinss: Say that the UA can substitute an average color if the gradient
           length is small [...]
   fantasai: Just define what happens at zero. Everything above zero is handled
             by pixel-rounding, which we don't speicfy
   TabAtkins: So should I specify averaging color?
   dbaron: Need to specify color space to average in
   shepazu: So what happens when you zoom in?
   TabAtkins: That depends on implementation
   <ChrisL> @dbaron yes, you do
   TabAtkins: If you zoom enough you hit rounding issues
   <ChrisL> @tab that is always the case. welcome to the world of non-financial
            computing which uses fixed precision arithmetic
   TabAtkins: I want to make sure ChrisL's case is handled
   TabAtkins: is allowed to handle, don't know if I can require it
   ..
   TabAtkins: I can't must without being precise
   shepazu: It's not as important to specify the behavior at 1px when it's been
            defined as 1px, it's what the rendering is.
   <dbaron> I think Peter's suggestion was good.
   shepazu: Important part was ... as you zoom in that 1px width is now 50
            pixels it should have the whole gradient
   shepazu: You can test that -- chris just wrote a test for that.
   shepazu: You haven't been dealing much with things like scale, but you're
            going to be, so you're going to run into this problem
   <ChrisL> css transforms
   Dean: We all know the implementers are going to do the best they can.
   * fantasai peterl should type his proposal
   * fantasai didn't catch the details
   * ChrisL missed the nanoPx also
   plinss: This is very simply specified.
   plinss: You try to not overspecify it.
   plinss: When the UA has knowledge of the output resolution, it's allowed
           to substitute an average color for the repeating color when the
           device does not have the resolution to capture the gradient
           correctly.
   plinss: It lets everybody do the right thing to the best of their ability.
   RESOLVED: Accept plinss's proposal.
   * ChrisL is okay with that
   <arronei> I want my infinite resolution monitor

   TabAtkins: Image values is becoming divergent in implementation stability.
              Some features like gradients widely implemented, others have no
              impls or are just beginning implementation.
   TabAtkins: In the interest of getting gradients unprefixed as soon as
              they're sufficiently stable, I'd like to either pull gradients
              out into a Gradients spec, or go through and kick a bunch of
              stuff into css4-images
   TabAtkins: specifically, the image() function, the cross-fade() function,
              and image-* properties
   <ChrisL> which is larger, the bits you cut out or the bits you leave in?
   JohnJansen: I think pulling out Gradients would make it easier.
   sylvaing: If you move the others, you're still splitting the document.
   <fantasai> ChrisL, about equal
   <ChrisL> oh
   fantasai: There's some things that should move just as fast as gradients.
             Also you need to define <image> type so we can reference it.
   TabAtkins: CR can reference WD, so it wouldn't delay CR, just REC
   TabAtkins: I just want to get Gradients to a point where we can kill prefixes
   TabAtkins: I don't care either way; WG decide for me.
   <sylvaing> http://dev.w3.org/csswg/css3-images/
   TabAtkins: So, we would keep 4.1. 4.3 is implemented in Mozilla, so keep
              that there. We can test it for now.
   TabAtkins: 4.2 and 4.4 would go
   TabAtkins: Gradients stay
   TabAtkins: 6 stays; object-* implemented already, rest is image sizing algorithm
   TabAtkins: Rest can be punted to level 4
   <ChrisL> I suggest splitting into css3 gradients and css3 images. because
            css4 images sounds like its years away, just from the name
   <fantasai> ChrisL, we'll publishing Selectors 4 next month ;)
   <ChrisL> my point about perception stands, regardless of any actual facts :)

   dbaron: Things without 2 impls should be at-risk
   TabAtkins: 9 is a separate issue we need to discuss
   smfr: Seems we need cross-fade() to interpolate gradients
   Florian: We could pull back into 3 if it stabilizes before CR
   <ChrisL> @smfr you mean to interpolate as in a transition, not to draw
            the gradient?
   plinss: Any objections to splitting along the lines described?
   <smfr> ChrisL: my point is that interpolation of gradients and images
          should be in the same spec
   RESOLVED: Split css3-images as described

   TabAtkins: 3rd issue is about gradients directly
   TabAtkins: I've been messing with keyword definitions for gradients
   TabAtkins: Right now you can specify linear gradients by keyword or angle
   TabAtkins: Some very informal polls on twitter, if you ask someone what a
              gradient with top should do, they agree with the spec
   TabAtkins: If you ask them about angles, they agree with the spec
   TabAtkins: If you ask them both at the same time, they say they should be
              the same, despite that being inconsistent with their previous
              answers
   TabAtkins gives statistics for his sample size of < 20
   TabAtkins: Given this, I think the angles are very easy to see, but the
              way keywords work right now is confusing
   TabAtkins: So I'm thinking we should drop keywords and work them out
              better for level 4

   <TabAtkins> data:text/html,<div id=one></div><div id=two></div><style>div {margin: 50px; border: thick solid black;width: 
520px;height: 300px;}#one {background: -webkit-linear-gradient(top left, red, white, blue);}#two {background: 
-webkit-linear-gradient(-60deg, red, white, blue);}</style>
   TabAtkins: We have an issue that corner-to-corner gradients, for example,
              are not sufficiently pretty.
   <bradk> here's mine: http://www.bradclicks.com/cssplay/linear-gradient/corner-to-corner-gradient.png
   TabAtkins: The top one is what corner-to-corner gradients currently do
   TabAtkins: The gradient bands are perpendicular to the diagonal gradient line
   TabAtkins: But the lower picture is what people actually expect/want
   TabAtkins: The two are different by the angle being reflected over the
              line y=x
   <dbaron> data:text/html,<div class=one></div><div class=two></div><style>div {margin: 50px; border: thick solid 
black;width: 520px;height: 300px;}.one {background: -moz-linear-gradient(top left, red, white, blue);}.two {background: 
-moz-linear-gradient(-60deg, red, white, blue);}</style>
   TabAtkins: one is 30deg other is 60deg
   <dbaron> (for those who don't want to use WebKit to look at it :-)
   Brad: Another way to say is that for corner to corner, the hypothetical
         midpoint connects the other two corners
   TabAtkins: With the current spec, the further the rectangle is from a square,
              the more it looks like a sideways gradient rather than a
              corner-to-corner one
   TabAtkins: Given this issue, I want to drop keywords for now and address
              them in level 4

   bradk: Keywords are the most popular way of doing this right now, mostly
          vertical or horizontal gradients.
   Brian: Instead of up top and bottom, use upwards and downwards and instead
          of left and right use leftward rightward
   Brian: And remove the paired keyword corner options
   plinss: If we do partial keyword option, then we're locking in our syntax
           and it'll be incompatible with our future syntax.
   plinss: We'll get into a situation where we dislike our legacy keywords
           and can't change them.
   TabAtkins: Could use a different function
   dbaron: Authors really want gradients. At some point we need to stop fiddling
           with it and declare it ready.
   anne: We did that with border-radius, and by the time we got it sorted out
         they weren't popular anymore. :-)
   <arno1> We could just have "horizontal" and "vertical" as keywords
   Florian: We're not throwing out all of it, just part of it
   Florian: just the part we don't agree on it.
   TabAtkins: We solve the cases we know we need now, get them unprefixed,
              then see if the remaining cases are useful enough to care
   Brad: the only gradient generators online use the keyword types right now,
         and because we changed the angle definition, you can't get something
         that works
   Brad: People use prefixed versions for years.
   TabAtkins: We're not going to change prefixed versions
   Brad: Because we changed meaning of degrees, you can't make a backwards
         compat version
   TabAtkins: You write the prefixed versions with the old syntax, do
              unprefixed version with spec version
   various try to explain that prefixed versions aren't going to change;
   they'll change when they drop the prefix
   plinss: How vendors deal with them and their customers is up to them.
   Brad: I don't think we can pretend what we decide here is not going to have
         ramifications. If we don't have a committment that they won't do that...
         otherwise we wind up with something unusable
   TabAtkins: That's why nobody will do that.
   dbaron: We've done it plenty of times, but we probably wouldn't do it with
           this one
   Anne: It worked fine for border-radius, -moz-opacity, etc.
   Brad: I'd like to keep the keyword going and figure it out before we publish
         it.
   Arron: Do you have a problem with upwards/downwards/etc
   Brad: As plinss pointed out, it'll make it harder for us to get a consistent
         syntax later when we add corner-to-corner gradients
   TabAtkins: The future has potential. I'm confident I'm not blocking my
              ability to expand in the future.
   Brad: I don't see the syntax as being problematic.
   Brad: I don't think it needs to change.
   * fantasai thinks Tab's questions were skewed
   Brad: It's intuitive for a lot of people, and they've learned it, and do
         we really want to hold up the spec for this.
   ...
   smfr: I'm concerned about having multiple gradient functions. Do I need
         linear-gradient or corner-gradient?
   smfr: This will just add to the confusion.
   TabAtkins: I think we can have a syntax that's different enough there won't
              be a parsing ambiguity
   Brad: "from top" would be close to current syntax and resolve ambiguity
   Brad: "left" -> "rightwards" is more different
   plinss: The question was about whether to drop the keywords, not about
           what they should be
   plinss: So do we drop the keywords, or go offline and figure it out
   TabAtkins: I want to drop the corner keywords
   plinss: Sounds like we're don't have consensus
   plinss: Take it to email/telecon

   plinss: Any other gradient issues?
   Brian: Premultiplied? Keep it don't keep it have options?
   TabAtkins: I think premultiplied produces most attractive gradients in
              common cases blending with transparent.
   TabAtkins: I can go either way, depending on implementers
   fantasai: If you go other way, then make 'transparent' magic.
   TabAtkins: I don't want to make transparent magic.
   Brian: Drop 'transparent' keyword, make everybody use rgba()
   Tab: If we're going to go non-premultiplied, then disallow use of
        'transparent' and make everybody use rgba()
   fantasai: That's horrible. You're making the author do the work.
   Brian: You have the same problem with transitions.
   fantasai: gradient from color to tranparent is very common use case
   smfr: Reality is that if we go with premultiplied we won't have it
         working correctly on Mac for another year or so
   anne: If it's just a year, I say head for the future.
   smfr: It could be more than a year.
   Vincent: Example of where premultiplied looks better?
   <nimbupani> http://jsfiddle.net/rK9Pd/11/show/
   <nimbupani> (check in webkit vs opera)
   TabAtkins: yellow to transparent, in premultiplied goes from yellow,
              fading to transparent
   TabAtkins: in non-premultilied, goes through an ugly grayish greeny color
   TabAtkins: If you go red - transparent - blue, if you want to make it
              work correct in non-premultiplied, you have to write red,
              transparent-red, transparent-blue, blue, placing transparent-blue
              and transparent-red at the same spot in the gradient
   plinss: Why don't we want to do premultiplied?
   TabAtkins: It's not natively available on some platforms
   smfr: We'd have to get libraries to add it
   Brian: Alan Gresley was asking about non-premultiplied gradients because
          there are some cases that you'd want that result
   TabAtkins: You could simulate it by manually arc it through the color
              space, it's tricky, but doable, and a very uncommon case in
              comparison
   Someone asks who supports premultiplied today.
   Brian: I had good results with Opera
   TabAtkins: With Opera and IE we'll have 2 impls, so let's stick with that.
   RESOLVED: Use premultiplied colors for gradients and transitions

   shepazu: At the outset of this effort, there was discussion about remaining
            compatible with SVG  gradients.. was that abandoned?
   TabAtkins: No. SVG doesn't have alpha colors.
   shepazu: Talking about geometry
   TabAtkins: Yeah, I don't think that's useful. But I was going to talk
              tomorrow about using SVG paint servers in CSS or CSS gradients
              in SVG.
   shepazu: So an engine supporting both will have to support two different
            things.
   TabAtkins: Yes.
   plinss: Ok, let's discuss that tomorrow. Grids.

   * ed wonders what this meant: "TabAtkins: No. SVG doesn't have alpha colors."
        (most if not all browsers already support rgba/hsla syntax in svg
        colors/gradients, also there's stop-opacity in svg gradients)


CSS Grid Layout
---------------

   Phil: My name is Phil and I'm from MS.
   Phil: We recently published new editor's draft. Hoping none of it's
         controversial so we can go through it quickly.
   Phil: With one possible reduction in functionality in grid template property
   Phil: specifically, assinging display types to grid pseudos
   ACTION Phil: Post notes to www-style or www-archive so they can be put
                in the minutes

   <smfr> http://dev.w3.org/csswg/css3-grid-align/
   Phil: 7.2 covered explicitly defined grid cells, creating named grid cells
   Phil: You could place children of the grid into them. We're removing that
   Phil: Removing grid-stacking property, which said which layout this
         explicitly-defined grid cell would be using
   Phil: The other mode it had was layer, which was the default layout type
         for a grid cell so items would layer on top of others
   Phil: When we presented that at MV ...
   Phil: Talked about creating flows inside a grid cell
   Phil: And assigning display types to the grid cell
   Phil: This was about creating presentation-specific structure through
         declaration of these grid cells, trying to remove concept form the
         grid layout spec
   Phil: We also added new paragraph about grid cell concept. We still have
         logical notion of a grid cell, but it's just an alias syntax for
         referring to a region of the grid.
   Phil: But we're saying it's not stylable
   Phil: It's just a way to name a spot on the grid

   Phil: In section 6.4 , repeating columns and rows. We got some feeedback
         that the named lines syntax we had didn't make sense inside repeating
         syntax
   Phil: Since it defined that only the first occurance of the name would be
         honoree, and purpose of repeat syntax is to replay the grid lines over
   Phil: Added issue as to whether to remove that ability from there
   Phil: Any feedback, send it, otherwise we'll remove
   Phil: We also had another isuse on the grammar, for grid columns and grid
         rows
   Phil: So we changed from ... to ...
   Phil: I'll let you figure it out; trust me the new one is better.

   Phil: Section 7.1 anonymous grid cells, we just added some language about
         relation between grid cells
   Phil: Now it's just logical container, what does it do to grid items inside.
   Phil: Define them as containing block
   Phil: And we said how they came into being, added language defining
         dimensions of the grid cell etc.

   Phil: Next is explicitly defined grid cells, 7.2 is gone
   Phil: Defining grid cells with a template is still there
   Phil: Still use the ascii-art syntax
   Phil: Keeping around grid-cell property, just don't have pseudo-element
         selector
   Phil: Can still define grid, and put things in it
   Phil: with that

   Phil: Section 7.5 automatic placement of grid items.
   Phil: It's no longer what we're thinking, so removed note
   Phil: ...
   Phil: Importance of automatic placement, some language about fixup of grid;
         it matches language in flexbox
   Phil: And we noted that if we don't have this fature, the fixup isn't useful
   Phil: Everything just gets dumped into first grid row. We're planning to
         leave in, so this is just an observation
   Phil: I just renamed section 8.1 .. size of grid items.
   Phil: Needs more work; need to specify box model calculations
   Phil: So if going to be stretched, questions like whta if you have a replaced
         element with intrinsic ratio ...........

   Phil: 10 calculating isze of grid tracks. Don't know if anyone is
         implementing, or thinking of implementing, but if so, we've published
         some pseudo-code about sizing these bits of the grid.
   Phil: Some bugs in it still
   Phil: We'll update a few more times before pushing to WD
   Phil: Lastly all these changes captured in Appendix A
   Phil: That is everything we have changed. The biggest piece is obviously
         the inability now to create these grid cells that you can give a
         display inside to control how they layout their contents, does
         anybody have objections to removing concept from the spec?
   TabAtkins: Ok with it, majority of my use cases don't need it.
   TabAtkins: But if I want to use this with regions, I need to now insert
              dummy elements to position them with grid ...
   TabAtkins: I greatly disagree that I should put dummy divs in my doc
   Markus: We think that should be defined somewhere other than grid
   TabAtkins: I hate put junk into my page for the sole purpose of styling.
   Tab tries to explain the difference between semantic markup and stylistic
       presentation to the MS folks
   Steve: Aren't templates a little bit of both?
   TabAtkins: As long as we keep in mind that we might want to do this more
              generalized in the future, then I'm cool.
   <bradk> If the CSS is creating the pseudo-elements, then conceivably more
           regions can be created to accomodate more content.
   Vincent: We have a resolution on this from the morning.
    * fantasai agrees with Tab
   ...

   Alex: One issue that we discovered ... which was that alignment in grid
         is currently different from alignment in flexbox
   Alex: What we discussed yesterday flexbox alignment, we kinda liked the
         idea of what grid is doing now. We're going to come up with a
         proposal that will make something consistent between the two.
   TabAtkins: Don't think they need to be different when both flexing and
              aligning stuff
   Markus: Q for Peter, we experiment with named lines, and ended up with
           very long strings.
   Markus: Is there a way to shortcut this somehow? Authoring becomes awkward.
   Phil: This example uses template
   Phil: It only takes one letter to name a position
   Phil: with named grid lines
   Phil: You end up putting 4 strings for each item that you had
   Phil: It gets a little verbose
   Phil: I think in practice if you have a grid, and have a large number of
         grid items
   Phil: And don't want to renumber them, you probably won't use named lines
         anyway
   TabAtkins: What wins if you use grid-rows, grid-columns
   Phil: If the grid cell exists, then it wins
   TabAtkins: What properties apply to grid template?
   ...
   Phil: You can only use ascii letters in grid template
   Florian: Disallowing punctuation doesn't disallow Chinese characters or
            accented characters...
   TabAtkins: Most reasonable layouts won't use 26, but last year I was
              looking at some very complicated layouts that were pushing it
   Arron: I had 180 in a layout I did
   TabAtkins: I think you should say any single character
   fantasai: grapheme cluster
   ...
   <dbaron> I wouldn't allow more than characters that are allowed to start
            identifiers.
   Phil: Would you use numbers ... ?
   dbaron: That includes most of Unicode except some ascii punctuation and stuff
   plinss: Where it gets unweildy with grid names, it's not so much where
           they're defined as where they're used
   <dbaron> template: "北北北北" "西中中东" "西中中东" "西中中东" "西南南东";
   ...
   plinss: I'm not concerned about the verbosity of the grid columns declaration
   plinss: If you line it up like that, I think it's readable
   plinss: Later when you do the grid-column ...
   Phil: You have up to for lines for positioning, so that's not too bad.
   Phil: But if you have a lot of grid items, that gets quite large
   plinss: Depends on how large your grid is
   Phil: No issues open on it, these are just some comments we got back
   plinss: Maybe you can have something that maps grid cells back into named
           grid lines
   plinss: Right now you can only do that with template.
   plinss: What if you could define a grid-cell "foo" defined by these named
           lines
   plinss: You're not defining the grid template, so not single-letter names;
           use multi-character names
   Phil: We had ::grid-cell() pseudo that could do that
   Phil: It was styleable enough that you could specify the  ...
   Phil: Ultimately we pulled that out
   Phil: Anything else?

fr unit and flex
----------------

   TabAtkins: Alex and I were talking about dropping the 'fr' unit and just
              using the flex() function for flexbox
   Alex: Flex function can do everything fr unit can do in flex, but fr unit
         is just a shortcut for one of the use of flex function
   <dbaron> Isn't 'fr' a shortcut for one of the uses of the flex() function
            that requires all three arguments?
   Alex: In a grid fr is a basic of how it is calculated
   Alex: it would be .. also allow flex function in grid, in which case you
         could replace fr unit with it or have both
   Phil: right now we have minmax function, and can mix that with min-content,
         max-content keywords
   Phil: Would we introduce flex() function there?
   Alex: flex function has flexibility and preferred size
   Alex: ...
   Alex: Auto and flexibility at once.. produces the same calculation ..
         maximum, however preferred size of column based on content
   Phil: There's just an issue we haven't resolved in the spec now
   Alex: For flexbox you don't specify 50 values for an items, so flex()
         being longer than a unit is not a big deal, but on a grid probably
         wouldn't want to replace fr unit with flex
   Alex: Make it even longer
   Alex: So if in grid definition fr is shortcut for flex(), we could keep
         it for flex
   TabAtkins: I'm uncomfortable with two of us using different notions of flex
   dbaron: fr right now is equivalent to flex() on a basis of 0, and 0 is
           not the default for that third argument
   TabAtkins: I changed flex() ...
   TabAtkins: If you say flex(1), you start from zero
   TabAtkins: That's not what my spec says right now
   Alex: the omitted preferred width should default to initial value
   TabAtkins: Ok, we need to discuss this
   dbaron: I agree with Alex, but I think that's another reason to keep fr.

CSS Positioning
---------------

   Arron: We submitted our proposal for floats and positioning, and we decided
          to split those. Alex volunteered me to do the editing
   <arronei> http://www.interoperabilitybridges.com/css3-positioning/
   Arron: So you can take a look at it.Not too many differences from 2.1
   Arron: Most of it's what 2.1 says, with some little clarifications of
          handling our new value. So you won't see a lot of differences.
   Arron: Will jump straight to some changes.
   Arron: So our first change that we have here is page positioning.
   Arron: What this defines is a way to go straight for the initial containing
          block, much like fixed positioning does but without fixing on the page
   Arron: So size and positioning based on initial containing block
   Arron: It'll go all the way to the initial containing block, and positioning
          off of that box.
   Arron: That's the first part.
   smfr: How is it different from position: fixed
   Rossen: If we create a region each the size of containing block, you want
           to have one positioned to the current region
   Rossen: Don't want to rely on how many relative and abspos elements in your
           ancestor chain
   Rossen: Different from position: fixed because in scrolling media, it's
           fixed to initial contianing block. So element scrolls along with
           the rest of the content
   Rossen: Similar to abspos content that has no positioned ancestor
   Rossen: Whereas fixed replicates
   Rossen: Position page was specific to design so you can target only the
          current page, and unlike position: fixed; position: paged;
          elements ... you can position negatively, and you can overflow,
          and that's just fine, whereas fixed position that just clips
   dbaron: So it's positioned on the current page relative to its placeholder.
   fantasai: My concern is that you'll get a layout that makes sense on
             paged media, but breaks in scrolled. Opposite problem of fixed
             positioning.
   fantasai: e.g. if you use this on a 15-page document, positioning 15-20
             things throughout the document across the 15 pages, looks fine
   fantasai: Load that into a scrolled view, and everything piles on top of
             each other in the first screenful, and then scrolls away with
             nothing in the rest of the document
   ...
   Alex: We should have discussion of what are different aspects of paged media
   Alex: Some means it's non-interactive, you're on paper
   Alex: Some of it means you're paginated
   Alex: From pov of layout, it's tempting to apply paged media to regions.
         But it's not paged media
   Alex: Should we have a new media type?
   fantasai: I think so.
   Arron: What I'm trying to get here is, we have this defintion right now,
          it may need more work as fantasai points out.
   Arron: What I'd like to do is put it up on W3C as an actual editor's draft,
          so we can start to shape something that works
   plinss: Anybody objecting?
   RESOLVED: Put CSS3 Positioning draft on dev.w3.org

   Arron: That's pretty much it. Please review once it's up
   plinss: Some flexbox issues to get back to?
   TabAtkins: Haven't had time.
   Alex: Directions and alignment; need to ...
   plinss: Meeting closed.

Received on Wednesday, 3 August 2011 05:38:38 UTC