W3C home > Mailing lists > Public > www-style@w3.org > November 2010

Minutes and Resolutions TPAC F2F 2010 Tuesday Afternoon: Logical layout, Font features, Position-Layout, Inline transforms, Haptics

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 16 Nov 2010 15:45:07 -0800
Message-ID: <4CE31783.9010501@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Logical Layout
--------------

   Long discussion on logical (start/end/before/after) properties or values.
   No consensus. Dropped from css3-writing-modes draft.

Font Features
-------------

   Discussed proposal to create font-specific font feature name maps.
   Syntax variants were discussed, with the goal of making the syntax
   reflect better the intended compounding behavior of the declarations.

Position Layout
---------------

   Tab Atkins presented a proposal to position boxes relative to other
   boxes. RESOLVED: add to charter as low priority. (In case Tab finishes
   everything else he's signed up for first. ;)

Inline Transforms
-----------------

   Discussed application of transforms to inline elements broken into
   multiple boxes due to either bidi or line-breaking.

   RESOLVED: transforms apply to bounding box of the inline. Mark
             application of transforms to inlines at-risk. (Grab
             bounding-box definitions from old css3-background
             background-break drafts.)

Haptics
-------

   Ilkka Oksanen presented a proposal for haptics controls to mimic
   OS-defined widgets haptic responses. Some concern about reintroducing
   the problems with system colors and/or the 'appearance' property.

Other
-----

   Brief digression into MultiCol.

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

Present:
   David Baron (partial)
   John Daggett
   Elika J. Etemad
   Sylvain Galineau
   Richard Ishida
   Koji Ishii
   John Jansen
   Håkon Wium Lie
   Aharon Lanin
   Peter Linss
   Alex Mogilevsky
   Steve Zilles
   others?

   LOGICAL LAYOUT

Scribe: Sylvain
   fantasai starts reviewing section 7 of
 
http://dev.w3.org/cvsweb/~checkout~/csswg/css3-writing-modes/Overview.html?rev=1.37&content-type=text/html;%20charset=iso-8859-1
   <dbaron> http://dev.w3.org/csswg/css3-writing-modes/
   http://dev.w3.org/csswg/css3-writing-modes/#abstract-layout
   fantasai: i could not come up with a use-case for making overflow-x
             and overflow-y absolute
   dbaron: people could have an expectation of what x and y map to ?
   fantasai: so y is the block direction and x is the line direction
   <dbaron> transforms has translateX(), translateY(), skewX(), skewY()
   jdaggett, dbaron: x and y are used for transforms and map to a physical
                     concept
   jdaggett: this is a really large change. the use-case is not clear to me.
   jdaggett: we are talking about transforming coordinate systems within
             the page
   plinss: it doesn't mean a true coordinate transform. this is attempting
           to solve a specific problem.
   plinss: it's just keeping overflow-x instead of having
            overflow-line-progression-direction
   dbaron: i think overflow-x and overflow-y horizontal and vertical (respectively)
   <dbaron> ... and the spec should use the terms block-axis and inline-axis
            rather than redefining x-axis and y-axis
   jdaggett: why does vertical text require these changes ?
   szilles: this is similar to asking why we need both flexbox and layout.
            we think they are valuable because they fit to certain tasks.
            likewise, these might be useful in some cases for people who
            use vertical text. Murakami-san's showed that it helped with
            maintenance.
   jdaggett: if you author content in both modes, yes
   jdaggett: this is still not related to vertical text
   aharon: logical properties are not just related to vertical text, they
           also matter for bidi
   aharon: the use-case for logical properties - start, end - in bidi is
           not theoretical
   aharon: an application that needs to support UI in different languages
           currently needs to provide different stylesheets.
   aharon: they're the same stylesheets, one effectively generate from the other
   <timeless> s/start/(padding,*)-start/
   <timeless> s/end/(padding,*)-end/
   aharon: e.g. margin-left in this stylesheet becomes margin-right in the other
   jdaggett: but is the stylesheet for vertical text really going to be a
             rotation of the western ltr stylesheet ? The design is not
             completely symmetrical e.g. controls may not rotate
   jdaggett: authors want to be able to describe what they'll do for this
             writing-mode vs. that other one.
   fantasai: this is not about making every automatic; there will still be
              a lot of fine-tuning e.g. drop shadows might have to change
              side
   fantasai: but this should get you 90%+ of what you need. for instance,
             for a book.
   howcome: you do want to set different values. duplicating properties
            does not address the problem
   dbaron: I think john is asking whether there is a use-case for having
           something that is vertical in one context and horizontal and
           another on the web. this is not about asking whether there is
           a use-case for vertical
   fantasai: is sharing the stylesheet between ltr and rtl a valid use-case ?
   fantasai: but if I want to do the same thing for my Japanese translation,
             it will not work ?
   jdaggett: this is not at all the same typography. Japanese layout is not
             rotated english
   jdaggett: in the webkit UA stylesheet, the default margin for paragraphs
             is 1em 0px. that's not a valid default for vertical Japanese
             paragraphs
   koji: Whether paragraphs are separated by 1em margin or no margin +
         indentation is not a vertical vs. horizontal case.
   koji: If you talk about blockquote default stylesheet, you want the left
         and right margins to 2em in horizontal mode. But in vertical mode
         you want top and bottom margins
   jdaggett: the claim that a UA stylesheet can be made to work as is by
             using logical properties is not true. that use-case is not
             addressed by logical properties
   jdaggett: a default for Latin text cannot be used as a default for
             Japanese text
   fantasai repeats koji's explanation to deaf ears
   fantasai: You're arguing that the default UA stylesheet, which specifies
             suboptimal layout for Japanese text regardless of whether it's
             horizontal or vertical, must handle proper japanese layout in
             vertical, but for horizontal layout it doesn't matter
   <timeless> q+ to ask what percentage of the problem needs to be solved
   r12a-nb: I thought the goal was to have the ability to move horizontal
            japanese to vertical japanese
   r12a-nb: I find logical properties much easier to use in practice
   jdaggett: the issues are: what do we need to support and change to do
             vertical text intelligently. then there are things that make
             it more convenient to write stylesheets. these things have
             been merged together
   jdaggett: retrofitting virtual properties in CSS is a large change.
   jdaggett: this doesn't address all the properties that may need to be affected
   fantasai: it covers all the properties in CSS2.1
   jdaggett: but what about CSS3 properties such as border-radius ? what
             about 2d transforms and their coordinate spaces ?
   jdaggett: I don't think any of this is required to support vertical text.
   kojiishi: but what if Japanese users want to be able to change margin
             and padding logically ?
   jdaggett: then let's see what we can do for margin and padding
   szilles: the top and left are irrelevant to the task of laying out lines
            in blocks. I want to set properties on the beginning of the line,
            the end of the line, on the block etc.
   * fantasai notes that we are discussing the very last section of the draft,
              with several intervening sections, and there's no way we're
              going to get to any of them now
   * sylvaing is in some kind of minuting hell
   * timeless could try to help
   * timeless is not likely to be able to identify names
   * sylvaing it's all right. just that we're going in a loop
   jdaggett: I don't think we should do this in one fell swoop
   jdaggett: I think we should add start and end keywords where needed
             e.g. in text-align
   jdaggett: And then for margins and padding, we just add 'logical'
             keyword to the shorthands
   jdaggett: and not deal with, e.g. border properties
   kojiishi: so you're questioning the number of properties that should
             be logical ?
   jdaggett: I think having a logical keyword in a small set of relevant
             shorthands is enough
   kojiishi: so you're not saying all margins should be physical
   * timeless frowns, does anyone have a link to real .jp sites that use
              vertical layout in IE?

   jdaggett: I don't have a problem with retrofitting logical into the
             margin shorthand
   jdaggett: I think a logical keyword on the margin shorthand is sufficient
  jdaggett: but we shouldn't try to make everything logical at once
   szilles: it was said that it was an expensive change. for instance,
            it's expensive in storage. but the alternative involves
            multiple stylesheets. i think the computational issue is
            a red herring
   <fantasai> szilles refers to messages on the mailing list that discuss
             the perf impact
   howcome: you're right, it's not a blocker. but it's expensive in other
            ways: for authors who get a lot of new properties
   howcome: adding a keyword to a shorthand, otoh, is reasonable
   howcome: likewise, we could have keywords for inside/outside for printing
   szilles: so you are OK with the ability to specify certain values in
            a logical coordinate system
   howcome: yes
   r12n-ab asks for an example of the logical keyword
   fantasai fights the flip chart
   <myakura> margin: logical? <length>{1, 4}
   the physical coordinate of the flip chart rotates in mid-air
   <howcome> margin: script 1em 0px;
   <howcome> margin: writing-mode 1em 0px;
   <howcome> margin: beas 1em 0px;           /* before-end-after-start */
   flip chart now stands in vertical-rl
   <howcome> margin: tobi 1em 0px;           /* top-outside-bottom-inside */
   jdaggett: so the logical keyword means that the shorthand values are
             slotted to top/right/bottom/left based on the writing-mode
   jdaggett: this proposal is not what is in the spec
   szilles: so the principal of logical direction has been accepted
   (howls of protest)
   jdaggett: not by doing this for so many properties
   (more Mozilla people standing up to make their point)
   (references to Dave Hyatt and Webkit)
   dbaron: hyatt implemented it quickly because webkit's style system
           architecture makes logical properties
   <timeless> s/easy/easy based on an assumption which is not required
                     by any specification/
   <dbaron> s/style system architecture/data structure for storage of
                                       declarations within declaration blocks/
   koji: But what you're saying is that you accept the idea of logical space,
         just not of scoping it so widely
   jdaggett agrees this is about scoping logical
   aharon: I think the situation with CSS2.1 with padding-right, padding-left
           etc. also involves a lot of properties already. why not just
           have shorthands ?
   jdaggett: I don't think we can remove properties
   aharon: but we may be able to deprecate properties that are harmful to i18n.
   * fantasai would like to get rid of the border-radius longhands :)
   * fantasai thinks that would help us more
   * glazou is afraid deprecating will have just no effect on the web
   aharon: it's much easier to add logical than turning left to top etc
   * glazou thinks turning directions is crazy
   <dsinger> I may be out of scope here, but if we are introducing a new
             idea -- edges that are relative to text or block progression
             directions -- introducing new words is better than overloading
             old ones, especially overloading left to mean top etc., which
             is just horribly confusing
   <fantasai> dsinger, nobody's actually suggesting that
   * dsinger ok, I thought I had heard that

   aharon: in several of our rtl localization projects, we had to introduce
           a rule in the system to make sure 'left' and 'right' did not
          appear in our CSS templates
   aharon: we use start/end or absolute-left/absolute-right. 95% of the
           time, people mean start/end
   koji agrees with aharon's assessment of physical vs. logical usage;
        same applies in horizontal vs. vertical
   aharon: most of the time when authoring a document that needs to be
           used both ways, logical is very useful

   Continuing on...
   fantasai: section 7 is split in multiple sections. 7.1. maps various
             parts of CSS21. No new values are introduced.
   fantasai: the only section that introduces new values is for caption-side
   fantasai: 7.3 is about HTML attributes; for replaced elements they're
             treated as absolute; on table elements these attributes are
             logical
   <dbaron> I don't think we should make width and height attributes
            behave differently for different elements.
   bert: some of the terms used are also defined in the Box Model module.
         we should look at any overlaps and synch up the two modules
   fantasai: yes
   (now addressing dbaron's point)
   dbaron: I think it's going to be very confusing
   szilles: the proposal is that for those elements  the width and height
            attribute are interpreted per the writing mode of the element
   fantasai: yes. the alternative is to ignore them
   dbaron: I'd rather add new HTML attributes
   szilles: see the other room
   dbaron: width and height attributes on table should not be logical
           while physical everywhere else as well as CSS width and height
           being physical. we should be 100% physical

   fantasai: section 8.1 http://dev.w3.org/csswg/css3-writing-modes/#logical-value
             defines properties that do before/after/start/end
   dbaron: note that caption-side already has 6 keywords
   jdaggett: I think vertical-align might need to have different defaults
             in vertical vs. horizontal. I need to confirm that but it'd
             need to default to middle in vertical
   jdaggett: vertical-align:auto ?
   howcome: I think adding new values is easier than adding properties
   fantasai: http://dev.w3.org/csswg/css3-writing-modes/#logical-page
   <timeless> http://en.wikipedia.org/wiki/Recto_and_verso
   <timeless> The verso is the "back" side and the recto the "front" side
              of a leaf of paper in a bound item such as a book, broadsheet,
              or pamphlet. ...
   fantasai: these have always been logical.
   fantasai: the original proposal was even and odd but if you change
             the page countering and things get confusing.
   howcome: I'm not sure we want to use the same stylesheet for an ltr
            book and an rtl book
   (arronei agrees with howcome)
   aharon: what about front and back ?
   fantasai: that is usually interpreted as the first and last page
   howcome: I think it's too early to spec the printing part of this.
   <timeless> [ a discussion of why 8.2 exists ]
   fantasai: the goal for these sections was to cover all of CSS2.1
   howcome: I don't think we should proceed until we understand spread layout
   <timeless> [ the explanation for why 8.2 exists is because
                page-break-before/page-break-after exist, as clearly
                indicated in the first indented paragraph of 8.2 ]
   <timeless> [ people explain how the binding side changes based on
                being LTR or TTB ]
   * sylvaing logical-writing-mode-discussion-avoid: always
   * arron sylvaing, we could always talk about text-replace :)
   <timeless> [ moving to 8.3 ]
   <timeless> [ howcome is asked if he objects to logical-height ]
   <timeless> [ howcome objects to adding any new properties ]
   <Zakim> timeless, you wanted to ask what percentage of the problem
            needs to be solved
   <timeless> [ i asked my question. jdaggett indicated he felt the
                proposal by fantasai, et al addressed 150% and he wanted
                something simpler which could be implemented and then we
                would later investigate what else needs to be added later ]

   Discussion of the proposal to only add a logical keyword to the shorthand
     and not add logical longhands
   dbaron: the challenge of implementing the logical keyword is the number
           of pieces of information you need to cascade separately. so even
           though you have the same number of properties for the author,
           the implementation deals with 8 underlying properties
   <dbaron> not really cascade, but store until you cascade
   * sylvaing right. and 8 values, not 8 properties...right ?
   jdaggett: i'm not saying this solves all use-cases. but adding the logical
             keyword in those two places potentially covers a lot of use-cases.
   fantasai: i'm fine with scoping it to margin and padding but if we add
             the logical keyword we should also add support for
             before/after/start/end longhands
   fantasai walks through an explanation of margin shorthand cascade and
            associated storage required...
   margin: logical 1em 2em 3em 4em;
                   b    e    a    s
   <timeless> [ fantasai draws a paragraph ]
   <timeless> margin-top: 5em;
   p { margin: logical 1em 2em 3em 4em; margin-top: 5em; }
   fantasai: if you don't store 8 values, margin-top would affect the
             physical right margin
   discussion of how inside/outside is even more fun to implement
   <fantasai> argument was that you only need to store 4 values plus a
              flag if you only implement the shorthand
   <fantasai> dbaron pointed out that it is in fact necessary to store
              8 values during the cascade
   <fantasai> fantasai walked through an example so people would understand
   <fantasai>   p {                b   e   a   s
   <fantasai>     margin: logical 1em 2em 3em 4em;
   <fantasai>     margin-top: 5em;
   <fantasai>   }
   <fantasai>                 4em
   <fantasai>           +--------------+
   <fantasai>     3em   |    LR  |||||||  1em
   <fantasai>           +--------------+
   <fantasai>                 2em
   <fantasai> Then we hit margin-top: 5em. Where do we store it?
   jdaggett: i think just having a shorthand is intuitive for authors.
   plinss: but you lose functionality. you can't just specify the start
   fantasai: I'm ok with just doing margin and padding for now. but i
             don't think the shorthands are sufficient
   plinss: wouldn't you need to do border as well ?
   fantasai: UA stylesheets only need margin and padding
   <timeless> [ howcome suggests media queries ]

<br>

   <arron> From what I have gathered over IRC we have talked about these
           few options for logical properties:
   <arron> a. leave everything as it is (all physical)
   <arron> b. create actual logical properties for all relevant cases
   <arron> c. alter only the shorthand properties to take additional keyword(s)
   <arron> d. create a small set of logical properties covering only a
              small set of cases
   <arron> d.1. create only margin/padding-(start, end, before, after)
   <arron> d.2. create only properties that do not take <length> as a value
                (e.g. border-*-color)
   <arron> There might be a few others that I missed from the conversation
           but I think this covers the scenarios that have been discussed.
   <arron> I am not saying that we should vote on these but I think we should
           really look at each one of these further and see the pros/cons of
           each. I am still not convinced that we all know the design/author
           side of these type of changes.
   <sylvaing> arron, the big question here was whether and how much of this
              was needed to address vertical text in the first place
   <arron> yeah but I don't think we know enough to actually make that
           decision yet.
   <arron> hence the reason why the conversation is probably going round
           and round
   <sylvaing> arron, yup. that it's very useful in some cases e.g. bidi makes
              it all the harder
   <arron> text-replace would solve the bidi cases probably.
   <glazou> mouhahahaha :)

  </br>

   * timeless notes we're discussing dropping things
   * timeless ... to drive to a FPWD

CSS3 Fonts
----------
Scribe: Tab Atkins

   scrivener's note: See previous discussion on this topic from the Oslo F2F at
     http://www.w3.org/blog/CSS/2010/09/02/resolutions_124
     http://lists.w3.org/Archives/Public/www-style/2010Sep/0003.html

   <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-variant-alternates-prop
   <jdaggett> topic: css3 fonts
   jdaggett: We've looked at this property before - opentype fonts have the
             capability to have alternate glyphs.
   jdaggett: There are many features that let you pick one of severeal
             alternates.
   jdaggett: In the past I specified this as just putting in a number to
             select a glyph.  A lot of people objected to this.
   jdaggett: It doesn't look nice, it doesn't play nice with fallback, etc.
   jdaggett: So fantasai and I sat down and created a way to establish a
             name-value mapping that applies to a family or families, so
             when you select an alternate you use the named value, not a
             number.
   jdaggett: If the font has that named value defined for it, it's used,
             otherwise it's ignored.
   jdaggett: The syntax is a new @-rule, @font-feature-values.
   jdaggett: Syntax is slightly different than what I had on the list originally.
   jdaggett: It takes several font variant definitions.
   jdaggett: Like
              @font-feature-values Jupiter Sans {
                  swash: delicate 1, flowing 2;
              }
   jdaggett: And then
              h2 { font-family: Jupiter Sans; }
              h2::first-letter { font-variant-alternates: swash(delicate); }
   jdaggett: There are some features tha tonly take one value, but some take
              multiple values.
   <jdaggett> http://www.typography.com/fonts/font_documentation.php?docID=6&productLineID=100026#sets
   jdaggett: [shows a font-variant page]
   jdaggett: This page goes through and defines all the selectors for
             different font features.
   jdaggett: So somebody using this font can enable these independently
             from each other.
   jdaggett: So in the opentype spec you have 20 of these features available.
             When you specify them via CSS you're specifying a set of them,
             so you want multiple values.
   jdaggett: The way I've defined this is that you can define multiple
             variants, and they all get turns on.  Like
               @font-feature-values Mars Serif { styleset: code 4 5; }
             which turns on two separate features under the single label "code".

   plinss: I think it's slightly confusing that you can use multiple
           declarations of the same type, and it means the same as a
           single comma-separated decl.
   fantasai: Maybe you could swap the name and the feature, so like
             "{ code: styleset 4 5; }"
   plinss: And what if you have another @font-feature later that defines
           another swash variant, frex?
   jdaggett: It continues to be additive.  If you use the same name for
             thee value, it overrides the previous value of the same name,
             but otherwise different names for the same feature collect
             together.
   fantasai: [Here] you have a different things for styleset and
             character-variant.
   jdaggett: Right.  character variants are just somewhat different than
             anything else.
   jdaggett: character-variant is the only feature that takes two values.
             Everything else takes one value.
   plinss: Suggestion for fixing the syntax implication - make @styleset,
           @swash, etc. sub-@rules underneath the @font-variant.
   [discussion of syntax variants]
   [appears to be consensus that later definitions for the same property/name
    should override]
   fantasai: In character-variant, since it only takes 1 or 2 numbers,
             if you put 3 numbers it should be an invalid rule, not just
             ignore the 3rd value.
   jdaggett: Are you okay with the syntax difference between character-variant
             and the other properties?
   fantasai: It's unfortunate, but not bad enough to overly object to.

   More discussion of possible syntaxes as fantasai types examples into a
   text editor.

   <fantasai> doodles:
   <fantasai> @font-feature-values Jupiter Sans {
   <fantasai>    @styleset code 5 6;
   <fantasai>    @styleset swishy 5;
   <fantasai> }
   <fantasai> @font-feature-values Jupiter Sans {
   <fantasai>   swash: delicate 1, /* not apply */
   <fantasai>          flowing 2,
   <fantasai>          delicate 7;
   <fantasai> }
   <fantasai> @font-feature-values Jupiter Sans {
   <fantasai>   swash: delicate 1; /* not apply */
   <fantasai>   swash: flowing 2;
   <fantasai>   swash: delicate 7;
   <fantasai> }
   <fantasai> @font-feature-values Jupiter Sans {
   <fantasai>    code: styleset 5 6; /* not apply */
   <fantasai>    code: styleset 8;
   <fantasai>    swishy: styleset 5;
   <fantasai> }
   <fantasai> @font-feature-values Jupiter Sans {
   <fantasai>   styleset {
   <fantasai>     code: 5, 6; /* not apply */
   <fantasai>     code: 8;
   <fantasai>     swishy: 5, 7, 9;
   <fantasai>   }
   <fantasai>   character-variant {
   <fantasai>     zeta: 20 3; /* cv20 = 3 */
   <fantasai>   }
   <fantasai> }
   <fantasai> @font-feature-values Jupiter Sans {
   <fantasai>   styleset {
   <fantasai>     code: 5, 6; /* not apply */
   <fantasai>     code: 8;
   <fantasai>     swishy: 5, 7, 9;
   <fantasai>   }
   <fantasai>   character-variant {
   <fantasai>     zeta: 20 3;  /* cv20 = 3 */
   <fantasai>     gamma: 12 5; /* cv12 = 5 */
   <fantasai>   }
   <fantasai> }
   <fantasai> @font-feature-values Jupiter Sans {
   <fantasai>   @styleset code 5, 6; /* not apply */
   <fantasai>   @styleset code 8;
   <fantasai>   @styleset swishy 5, 7, 9;
   <fantasai>   @character-variant zeta 20 3;  /* cv20 = 3 */
   <fantasai>   @character-variant gamma 12 5; /* cv12 = 5 */
   <fantasai> }
   <fantasai> @font-feature-values Jupiter Sans {
   <fantasai>   styleset: code 5 6, code 8, swishy 5 7 9;
   <fantasai>   character-variant: zeta 20 3, gamma 12 5;
   <fantasai> }

   fantasai: Problem with last option, even though it's more compact,
             is that repeating the declaration of a particular feature,
             it blows out all previous features
   fantasai: I think it's better to allow an additive syntax, so either
             the @styleset syntax or the selector-like one
   fantasai: The selector-like one has additive and overriding behavior
             that is is very closely analogous to existing CSS syntax
   jdaggett: In many cases you'll have a global style sheet that defines
             a bunch of feature, but the author might want to tweak a
            few more in a local style sheet
   jdaggett: in which case an additive behavior would be better than
             having a new feature declaration erase the old one

   Bert: This all seems very complicated for something that is already complex.
   cslye: Yes, but this isn't a feature that a normal author is going to use
          anyway.  This is basically just for opentype junkies.
   Bert: I also don't like the fact that the value names are author-created,
         not standardized.
   Bert: There was another proposal for just turning on variants inside of
         a @font-face rule, so you could just define several font names
         with particular variants baked in.
   jdaggett: That option is also there.

   [ Digression to talk about Corporate Style Sheets]
   Bert argues that this is complicated and people will have to learn it
     which is bad
   Timeless and Bert discuss corporate style sheets and how this will require
     local stylists to deal with syntax they don't want to learn
   Peter turns this example around and shows that this syntax allows better
     cascading behavior between corporate global and local style sheets
   Peter: Say I have a corporate style sheet that defines an @font-face rule
          and that turns on various features
   Peter: I want to turn on an additional two new features.
   Peter: You're saying I have to copy the corporate @font-face rule into my
          local style sheet and tweak it.
   Peter: A week later, corporate style sheet is updated, tweaking its
          features to be slightly different
   Peter: I don't pick up those changes because my @font-face rule overrides
          theirs
   Peter: Whereas if I use this syntax, I can pick up those changes because
          it's additive rather than overriding

   howcome: In 4.1, it says "[downloaded fonts] must not be made available
            to other applications or documents".  I think it should be clear
            that things like caching don't violate this requirement.

<arron> I am here
<johnjan> ah, hi arron.
<johnjan> we're waiting for the AC meeting to end, I believe.
<bradk> Hello
* arron waves to bradk from Seattle

CSS3 MultiCol
-------------
Scribe: fantasai

   Alex: Why aren't percentages are valid in column-width?
   fantasai: Because it makes more sense to use column-number
   howcome: And doesn't have the problem of what to do with 33% vs 34%

   Alex: Other issue was column rules in overflow columns
   Alex: Are rules drawn between overflow columns?
   howcome: yes
   discussion of column rules between empty columns
   howcome: both of them have to be empty

Position Layout
---------------

   <TabAtkins> http://www.xanthir.com/blog/b48H0
   Tab: Position-layout extends the positioning power by letting you
        position edges of boxes relative to other arbitrary boxes
   Tab: Some use cases...
   Tab: In Google Docs, for example, when you're doing annotations,
        you'll attach annotations to particular spans of text
   Tab: In that case you would set the top of the annotation to be
        equal to the text being annotation, and the other side to
        the doc edge
   Tab: Also want to measure this edge from this other edge
   Tab: Our layout for our experimental newsreader app is good, but
        can only be done with a ton of fragile CSS hacks
   Tab: There are three columns in importance of news
   Tab: and then the rows represent timezones
   Tab: Stories are titles, or title and picture and blurb
   Tab: Want to expand the story to take up the whole width
   Tab: Wound up using a JS constraint solver to do this switching
   Tab: Another issue is resize handles
   Tab: Want to position them relative to whatever image you want to resize
   fantasai: I'm a little concerned about prioritizing work
   fantasai: and you're editing a lot of drafts
   Tab: I want to work on this in the context of the CSSWG
   Tab: Want to have it in the charter
   several concerned about prioritization of work and amount of work items
   Tab: This is somewhat inspired by Daniel's proposals
   Tab: ...
   Tab talks about cycles and breaking cycles in the constraint solver
   Tab talks about expanding functionality of fixed and absolute positioning
   Tab: This is a superset of Daniel's proposal
   Alex: Is it specific to positioning, or do you want it to be more general
         and e.g. make this table row as wide as that table column
   Tab: Don't want to expand beyond positioning. If it gets to complicated,
        it gets very very tangled
   Alex ... Instead of positioning, could be a special layout type
   Alex: Instead of applying positioning anywhere, applies only within a
         particular element
   Alex: a special kind of container
   Tab: Interesting, but for now, I think I'd want to keep it as extension
        of positioning.
   Tab: But let's talk and see if we can satisfies the use cases along the
        lines you're talking about
   No one here objects to putting in charter as low priority
   RESOLVED: add to charter as low priority

Transforms
----------

   Tab: Had a question of transforms applied to inlines
   from Simon
   Tab draws some text and a span
   <p>
   .... <span>bla bla bla RTL RTL RTL bla</span> ...</p>
   Span breaks across multiple lines
   Tab: When you rotate, how do you rotate?
   Tab: First option is transforms don't apply to inlines
   Tab: Second option is to make a bounding box. Transform the bounding box.
   Tab: Third option is to transform each box of the element independently.
   Tab: Sub-issue: are bidi boxes transformed independently
   fantasai: I would go with the bounding box option
   Tab: what do you do with page breaks/column breaks?
   * dbaron notes ac meeting is ending
   fantasai: use same bounding box def as for backgrounds
   discussion of relpos
   and how that works

   Anthony: Browsers: Opera and FF, do not rotate text if you put in the span
   Anthony: Mobile solutions do rotate
   Anthony: I haven't tried multiline in SVG
   fantasai: I would just use the bounding box definition from the old
             css3-background drafts. Seems the simplest
   <arron> the simplest would be to not apply transforms to inlines.
   <fantasai> well, true
   fantasai: define 2 and mark it at risk (fall back to 1)
   RESOLVED: transforms apply to bounding box of the inline. Mark
             application of transforms to inlines at-risk. (Grab
             bounding-box definitions from old css3-background
             background-break drafts.)

CSS3 Values
-----------

   <johnjan> here we go
   dbaron: I don't have anything to say...
   arron, ping
   <arron> I don't see the removal of min/max
   <fantasai> wasn't it marked at-risk?
   <arron> I thought we said we were going to remove those
   <fantasai> no, we were going to mark them at-risk
   <fantasai> http://www.w3.org/blog/CSS/2010/10/19/resolutions_126
   <arron> Have all the updates been made? I am not seeing it in the Aug
           draft. Am I looking at the wrong version?
   <arron> Well If the updates have been made I have nothing more on this
           and we should just publish a new version

Haptics
-------

   Ilkka Oksanen (Nokia): Haptics proposal sent to www-style a couple months ago
   <ilkka> http://www.starlight-webkit.org/CSS/css3-haptics.html
   Ilkka: Names in proposal not important
   Ilkka: The use case we're trying to fulfill here is devices that have a
          touchscreen
   Ilkka: can then have tactile feedback that's linked to the user interactions
   Ilkka: Properties are style and strength
   Alex: I know nothing about the area. Looks like different kind of feedback.
   Alex: Seems like analogue of colors or sounds
   Alex: Kind of properties I would expect are ... vibrate ...
   Alex: I would expect that there are selectors that select when to feedback
   <dbaron> Aren't the descriptions of 'unchecked-checkbox' and
            'checked-checkbox' backwards?
   Alex: and then style the items
   Tab: Use case is mobile phone applications
   Tab: Using names rather than specifying effects is to match OS conventions
   Alex: Buttons etc. UI elements are in the system. Why doesn't it just
         launch the appropriate haptics?
   Peter: Use case is for adding button feel to things that aren't actually
          buttons
   jdaggett: So it's like the system colors?
   <dbaron> and the input[type="radio"] style also seems backwards (shouldn't
            it be -down rather than -up?)
   Peter: Have an issue where starting activation, ending activation might
          need separate effects
   Peter: Have same issue with transitions
   Discussion of conferring semantics
   Discussion of triggers
   Alex: Are there hidden triggers that are not available for any other
         feedback, like color?
   Alex: If a browser implementing this has to implement internal triggers
   Alex: Why not make triggers available to other effects?
   Peter: We had related discussion at Apple wrt transitions -- we don't
         have ability to trigger transitions in and transitions out
   dbaron: Doesn't seem to be related to :active
   dbaron: Just what happens when you touch the element
   Ilkka: The feedback is not related to how long you touch the element
   Ilkka: When I touch an element on touchscreen,  the vibrator is activated
   dbaron: The spec is defining this as an inherited property, which seems
           reasonable.
   dbaron: Don't see a problem with this applying to things that cannot
           be :active
   Peter: Does this apply to everything? Or only if I have something that
          has buttonlike behavior?
   Peter: What happens if I apply unlatch to a <span>?
   dbaron: Not a good idea to do that?
   dbaron: I think the default of the type being none is needed
   dbaron: given the strength default is none
   Peter: If I style a <span> like a button and add haptics, will it behave
          like a button?
   dbaron: No, it just feels like a button when you touch it.
   fantasai: This is like a property to make a sound when you click the
             mouse on an element.
   fantasai: except it's not a sound
   <dbaron> And the default style sheet shouldn't use '-webkit-'

   Peter: There are issues here similar to 'appearance', transitions, etc.
   jdaggett: How common is it for phones to implement all the types you list?
   jdaggett: Or rather, are all UAs on all phones capable of matching those
             types to something reasonable?
   jdaggett: We have this problem with system colors, where it only maps
             reasonably in Windows 3
   Peter: So should we scope this into the UI module?
   jdaggett: Also, would you want to do this to other types of feedback?
             e.g. iphone uses sound
   Peter describes a haptic mouse he had along time ago that gave the feel
         of running over a button when you cursored over a button

Meeting closed.
Received on Tuesday, 16 November 2010 23:45:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:34 GMT