- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 16 Nov 2010 15:45:07 -0800
- 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 UTC