- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 31 Aug 2010 05:32:01 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Please start a new thread for replies, unless you are correcting the minutes.
CSS3 Generated Content for Paged Media
--------------------------------------
Håkon would like to prepare the module for CR.
Several people feel many of the features would be better placed in
more appropriate modules, e.g. hyphenation to CSS3 Text.
Some features may be underdefined.
But nobody objected to any of the features fundamentally.
Wrt hyphenation:
- discussed hyphenate-resource property and use of local dictionaries
instead of specified ones
- discussed hyphenate-character property; it seems it should be able
to accept a second character for languages where a second hyphenation
character is used after the line break
- discussed whether control is needed to prevent hyphenation on the last
line of a page: plan to recommend the UA to prevent such hyphenation,
add a control only if market determines one is needed
- discussed possible use cases for specifying the hyphenation language,
but none seemed needed -- the hyphenation language pretty much always
matches the content language
- proposed to replace 'hyphenate-resource' property with an at-rule that
maps language tags to hyphenation resources, since hyphenation resources
need to be specified per language, but not per element. E.g.
@hyphenate-resource {
en-US: url(en-US.hy);
en: url(en-GB.hy);
fr: url(fr.hy);
}
* note from fantasai: this would allow more intelligent lang-code ->
dictionary mapping than using :lang() selectors and a property
Reviewed several other features including
- cmyk() colors, which were proposed to rename device-cmyk()
- bookmarks, which should have more examples added to explain their usage
- super-decimal counter style, which has been moved to CSS3 Lists
- line-box-contain, which needs more investigation
Hit Testing
-----------
- Plan to add pointer-events to UI module edited by Tantek
- Correct default behavior uncertain, needs testcases and investigation
RESOLUTION: try and move AC review of charter forward, to get UI module
in it and publish a LC asap.
Styling Attributes
------------------
- RESOLUTION: publish style attr as CR.
Media Queries
-------------
- Anne suggested including the media type definitions in MQ; WG
considers this an editorial issue.
- Reviewed status of test suite. Mostly waiting for another implementation
to fix all its parsing errors; Mozilla passes all tests.
- Anne suggested removing 'color-index'; WG disagrees.
Snapshot 2010
-------------
- RESOLVED: 2010 Snapshot is 2007 Snapshot + Media Queries
Selector Serialization
----------------------
- Need a Selectors 3.1 spec to define serialization and OM
(not required for UAs without an OM)
Flexbox
-------
- Discussed flex units and alternatives
- RESOLVED: Out-of-flow elements are treated as placeholders
during flexbox construction, similar to tables. ISSUE-138
http://www.w3.org/Style/CSS/Tracker/issues/138
- RESOLVED: 'max-width/height' on a flexbox child limits the size
of the element; if this results in a shorter box than any other
in its row, it is aligned as if box-align: before. ISSUE-140
http://www.w3.org/Style/CSS/Tracker/issues/140
- RESOLVED: Baseline of a flexbox is the baseline of its first
child. Note: this may be revisited based on use cases. ISSUE-141
http://www.w3.org/Style/CSS/Tracker/issues/141
- RESOLVED: box-ordinal-group also reorders stacking order; i.e.
it reorders the box tree. ISSUE-142
http://www.w3.org/Style/CSS/Tracker/issues/142
- RESOLVED: Preferred width of flexbox children is 'max-content'
not 'fit-content'. ISSUE-143
http://www.w3.org/Style/CSS/Tracker/issues/141
- Discussed distribution of negative space. Agreed that applying
flex calculation with negative space is not ideal; alternatives
to be investigated, including
- ignoring flex when available space is negative
- adopting TeX's glue algorithms
ISSUE-144 http://www.w3.org/Style/CSS/Tracker/issues/144
- RESOLVED: Contiguous non-replaced inline elements are wrapped
into a single anonymous block. Atomic inline-level elements are
individually wrapped into flexboxen. ISSUE-145
http://www.w3.org/Style/CSS/Tracker/issues/145
Multi-Column Layout
-------------------
- RESOLVED: Use border-collapse border-style behavior for column rules.
- RESOLVED: Column rules are not clipped by the multicol element
horizontally; but are drawn to the height of the multicol element
vertically.
- RESOLVED: Column rules are drawn "immediately below the border
(above the background) of the multi-column element".
- RESOLVED: Column-spanning elements have an effective column-span
of 1 when occurring in an overflow column. ISSUE-129
http://www.w3.org/Style/CSS/Tracker/issues/129
fantasai's post-meeting note: If a colspanning element has
multiple lines, and some of them fit inside the multicol element
but others don't, then the before-break and after-break halves
of the element will be laid out at different widths?
box-shadow
----------
- Specification of box-shadow's blur radius has been fixed.
- RESOLVED: Not altering stacking order of inset box-shadow to paint
over content. May add keyword to do this in the future.
- RESOLVED: Publish css3-background as CR.
F2F Scheduling
--------------
Tentatively scheduled: March 7-9 (MTW) 2010 in Mountain View
June 1-3 (WTF) 2010 in Tokyo
====== Full minutes below ======
Present:
César Acebal
David Baron
Bert Bos
Tantek Çelik
John Daggett
Arron Eicholz
Elika Etemad
Daniel Glazman
John Jansen
Håkon Wium Lie
Chris Lilley
Alex Mogilevsky
David Singer
Steve Zilles
Partial (late afternoon via phone + IRC):
Simon Fraser
Sylvain Galineau
Brad Kemper
<RRSAgent> logging to http://www.w3.org/2010/08/24-CSS-irc
Scribe: Bert
Tantek: Add UI to end of extra topics list?
Glazou: OK
<anne5> dsinger, http://dev.w3.org/csswg/cssom/ is the draft
<anne5> dsinger, last updated a couple of days ago; CSS Value API is the
thing that I want to work out next
howcome introduces Leif, from Opera
Leif introduces himself. Worked on microformats, among other things.
Interested in hit testing.
CSS3 GCPM
---------
howcome: GCPM is [not] the garbage collection module. :-)
howcome: We have two impls of most of the features.
howcome: Prince and AntennaHouse.
howcome: Last time we cut out the most experimental stuff.
howcome: What's left is ready for CR this year.
howcome: (First LC, of course.)
John: Hyphenation is more useful than just print, should move to
another module.
<glazou> +1
howcome: Several things are not just for print.
howcome: I *do* like hyphenation to move fast.
howcome: Not sure Text module will move faster.
Glazou: But the title of the module is "Paged"
howcome: A question about hyphen was how to do hyphenation dictionaries.
howcome: Could be a separate module,
Dave: As a naive user, I'd look for hyphenationin Text module
howcome: And how about a separate module?
Dave: That works, too.
John: Related to justification.
Tantek: What languages do the impls. hyphenate?
howcome: Whatever they have dictionaries for. Prince uses TeX hyphenation
algo and dicts,
howcome: The 'hyphenate-resource' points to the dict.
John: Format of those files defined?
howcome: No, like 'icon', it is not defined what the reosurce format is.
howcome: TeX is well-defined.
Fantasai: Fonts have a way to specify format.
John: It's not more than a hint, still need to ask server.
howcome: Should it be the same as in fonts, then?
John: One reason fonts is the way it is is that there was no font mime type.
howcome: OpenOffice uses a different format, derived from TeX but not the same.
howcome: So there is indeed a problem.
howcome: But the impls. expect to ship with their own resources.
John: Sometimes want to use system resource instead of the url of the
'hyphenate-resource'property
fantasai: Use an 'auto' value to allow local resources.
Dave: So you can get control by putting a 'local' value somewhere in the list.
Glazou: The property is currently meant for exteranl (additional)
resources only.
fantasai: Mention somewhere that UA doesn't need to implement
hyphenate-resource to be conformant.
John: Is that handled as a syntax error?
fantasai: Yes, exact as an unsupported property elsewhere
Steve: How does it show up? Do you need to parse the property?
fantasai: no
glazou: From a pov of testing, failing the test is still succes.
glazou: DOM doesn't matter for that.
howcome: A more experimental, but very useful feature is 'hyphens: all'
howcome: It puts a marker in the text at *all* possible hyphenation points.
John: Limit to certain number of lines?
howcome: See 'hyphenate-lines'
[Discussion about the keyword 'no-limit']
John: Can you hyphenate arabic?
fantasai: Yes, I think so.
howcome: Justification can be used with or without hyphenation.
Fantasai: Typical impl. is to hyphanate first, then justify the resulting
lines.
glazou: Hyphenate character: in some languages, you use a symbol both
before and after the break. Is it always the same character?
glazou: That has to be checked.
howcome: Do we need to go as far as support a pair of characters?
Steve: Ask the i18n WG...
glazou: If you have hyphenation, you need to do this as well.
[Dave gives example of old italian.]
glazou: May need a separate property.
howcome: Chris drew hanging hyphen. How do you do that?
fantasai: That is in Text module. hanging-punctuation
* glazou there's another _current_ european language using char before
AND after the hyphenation break
JohnJ: Could you find the proper character in the dict?
fantasai: Don't know.
howcome:Does anybody volunteer to do the research?
glazou: We originally thought for list module to only have something
simple. We were very wrong. Still not have all cases.
howcome: I'd say reasonable approach is to provide what TeX provides.
glazou: We have an I18N group, let's ask them.
glazou: When they don't repsond, we can go ahead ourselves.
Chris: Could make 'hyphenate-char' a shorthand for two properties.
fantasai: Not really ncessary to make separate proeprties if they don't
cacade independently. Just put two values in the property.
howcome: One common knob is to not allow hyphen on last line. No property
for that currently.
fantasai: Can suggest in the spec that UA *should* not hyphenate the last
line of the page.
glazou: It is not a "should."
<fantasai> People can ask for additional control in LC if they really
feel it's needed
glazou: 'hyphenate: auto avoid'?
John: Need a way to indicate languages?
fantasai: The lang= attribute.
John: But then need language selector. Can also mark the hyphenate
resource with a language.
fantasai: If the doc doesn't indicate language, it will not be hyphenated.
glazou: Why is the resource a property and not an at-rule?
howcome: Possibly use different dicts for different elements.
Dave: Could be a technical dict for special terms.
fantasai: But glazou was asking if that can be a global resource.
Steve: But if there are two languages?
fantasai: Need to set a global resource *per language*
Dave: Still need to suppress hyphens for certain elements.
glazou: Can still turn it off per element with the main 'hyphens' switch.
<fantasai> glazou's point is that there doesn't seem to be a need for
setting dictionary resources per element, only per language
per document
Steve: Say I want math and chemistry, would need two dicst.
[Discussion about wording: "try resources *in turn*, *in order*...]
fantasai: Compares more to 'font' or to @font-face'?
Dave: But the math/chem example is only a problem if there is a word
that it is hyphenated differently in them.
Chris: LANG= allows extensiona fter the dash: en-chemical, etc,
Steve: But then you ened to change your mark-up.
Chris: But it probably belongs in the mark-up.
glazou and fantasai draw on the board:
@hyphenate-resource { en-us: url(en.hy); ... }
howcome: What is the reason for at-rule over prop?
glazou: Performance (only one, and fewer props) and conceptual.
glazou: Performance is even a pb for batch processors, if style and doc grows.
<dsinger> if you need to differentiate your danish-mathematics from
your danish-chemistry because (for example) there is a word
that is hyphenated differently in the two, I *think* you
would be able to use a BCP 47 private use subtag, and still
associate hyphenation rules and dictionaries 'globally' with
a BCP 47 language tag
glazou: Would you wait for a download of a dict when rendering an element?
glazou: I want the at-rule to come before any other rules.
[several: seems not important to enforce putting it first]
Alex: I like the at-rule.
Tantek: Seems indeed analogous to @font-face.
howcome: How do you reference them in the style rules?
Glazou: The 'hyphens' property switches hyphenation on and off.
language settings associate the resources to the element
glazou: Let's talk about other topics, time is limited.
howcome: 'super-decimal' is a new keyword for list-style.
[several: already added to list module at last ftf.]
Chris: Refer to value of counter of a list item?
howcome: Yes, target-counter()
howcome: image-resolution...
fantasai: Will move that to image module.
Tab: I've been working on defining counter styles with at-rules. So far
works for nearly all. No need for many predefined keyword anymore.
Tab: Two or three are not regular and remain as keyword.
Tab: All others can be defined with rules in the UA stylesheet.
glazou: So GCPM should refer to that and allow at-rule-defined list numbers.
howcome: But shouldn't make GCPM depend on something that has no clear
time line.
[General discussion about moving forward and dependencies...]
* glazou likes the @counter-style at-rule *a lot*
* TabAtkins My first draft at a UA stylesheet for all the list-styles:
http://www.xanthir.com/etc/css3-lists-ua-stylesheet.txt
[howcome explains 'bookmarks']
Tab: HTML5 has an outline algorithm. Does that interact?
Steve: Independent.
Steve: In PDF, anything can be put in a bookmark, it's not necessarily
an outline. Could make a list of figures, for example.
Tantek: That example should be in the spec, to make clear what bookmarks mean.
howcome: Also, document not necessarily HTML, so not always defined how
to make a toc from it.
Chris: Yes, example of table of figures is good to add.
howcome: The spec should not become an introduction to publishing, but
some examples can be added.
howcome: Bookmarks are not restricted to those examples.
Molly: Show it with pictures.
hakon: But careful that rendering is not necesarily the same everywhere.
howcome: CMYK...
fantasai: Didn't we decide to rename it to 'device-cmyk'? To stress that
it is device-dependent.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2009Jun/0186.html
Steve: There are various specs, but different in several countries.
<dbaron> http://lists.w3.org/Archives/Public/www-style/2009Jun/0343.html
dsinger: Can't you add a way to specify the desired color space?
Chris: We had that discussion last time. howcome didn't want that at this point.
howcome: I'd rather not change the notation. It's implemented and the spec
is clear that it is device-depnedent.
Chris: SVG has 'device-cmyk()'
howcome: OK, then I will change it here, too.
[David remarks that "this page intentionally left blank" should really be
... *nearly* blank. :-) ]
howcome: Aligning baselines...
Chris: Is this diff. from multicol?
howcome: Yes, more advanced control over lines when there are images
somewhere in the text, e.g.
Steve: Also need that for page spreads. (Similar to columns.)
howcome: Proposal here is to use 'line-box-contain' property from line
box module (which is currently not being worked on).
glazou: From the example, I can't understand what the property does...
Steve: Easy enough to fix. Take Japanese, e.g., they need some sort of
"snap to grid."
Steve: So you need a way to define what the grid is and then say when
you to snap to it.
John: But nobody knows what a "line box" is.
glazou: Is this baseline aligning only for multicol?
howcome: Yes, although page spreads would be another application.
Steve: It really only matters for the body font. Headers rarely need
to be aligned.
howcome: Another proposal than 'line-box-contain' was
'line-stacking-strategy'.
Steve: XSL has that.
howcome: Yes, but XSL doens't have the 'grid-height' value that we need here.
glazou: Would aligning baselines be the default behavior for columns?
Steve: No, I don't think so.
[Glazou draws on white board...]
[Two columns, 2nd column has a big header in the middle.]
howcome: You want to be able to force the lines after that heading to snap.]
[Result shows last lines in both columns on shared baselines]
glazou: That could also be done by setting some special kind of height/snap
on that big element, rather than on the multi-column element a
a whole.
[howcome/Steve talk about other cases, Japanese, e.g., where that is
not enough.]
dbaron: I wrote 'line-box-contain' some years ago, there were reasons
why it worked better than 'line-stacking-strategy', but I would
need to study it again...
dbaron: The former allowed, e.g., to choose explicitly what is currently
quirks-mode behavior.
Steve: I will need to ask in Adobe if this is too limited.
ACTION steve: examine stack stacking, line box contain, and suggest a way
out of the problem.
<trackbot> Created ACTION-257
Bert: 'line-box-contain' also need a way to fix the problem of fallback
fonts chaning the line box height, i.e., a way to specify that
only the first available font influences the line box height.
Bert: FF seems to do that currently, but it's not per CSS2.
[10 min break]
Hit testing
-----------
[Leif introduces the topic, writes on whiteboard...]
Leif: Elements can overlap without one being descendant of another.
Leif: Imagine that one has transparent background and below is one that
expects click events.
Leif: Depending on where you click and on the browser, you get different
results.
Leif: In some browsers, the transparent bg blocks events, in others not.
<fantasai> isn't pointer-events supposed to address this?
Leif: So we'd like to see a standard for it.
Leif: Gecko & Webkit have a proeprty to specify behavior.
Leif: Can even be more detailed.
<dbaron> http://webkit.org/specs/PointerEventsProperty.html
Leif: But important is that there is a common default behavior, less
important *which* behavior it is.
Chris: SVG has 'pointer-events' property.
<ChrisL> pointer-events in SVG http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty
dbaron: Yes, but it talks about things like 'stroke' and 'fill'. So we
need a way to extend it to talk about CSS box model.
dbaron: Dean had a proposal for how to do that.
Tantek: I plan to work on that. Auto and none values seem interoperable,
at least.
<ChrisL> pointer-events
<ChrisL> Value: visiblePainted | visibleFill | visibleStroke | visible |
<ChrisL> painted | fill | stroke | all | none | inherit
<ChrisL> Initial: visiblePainted
Tantek: 'Auto' needs more specification.
Tantek: I just wanted to have 'auto' and 'none' for now.
Anne: But there is hardly interoperablilty.
Tantek: Two impls of those that do the same thing.
<anne5> http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-events-20100820.html
dbaron: Gecko/Webkit behavior is easy enough to specify.
Tantek: 'auto' means the front element gets the event.
Leif: Opera/IE close to SVG's 'painted' value, Gecko/Webkit close to 'visible'
dbaron: IE/Opera isn't really like 'painted'. They actually look at the
shape of the painted text.
dbaron: But not clear what the exact behavior is.
Tantek: So what does Opera do?
Tantek: Events include selecting text.
Leif: Not sure what we do with that.
Tantek: Current draft has basically the 'visible' behavior as default.
<anne5> Hixie's draft: http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
<dbaron> http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
Leif: Hixie analyzed IE behavior a few years back. Opera used that as
base for its behavior.
Leif: Can IE switch? Since we have IE people here...
Alex: I would need to look at what is happening now. I think we implement
the property in some way, not sure what it does. It has the SVG values.
JohnJ: Arron is testing right now...
ACTION Arron: make a test for the pointer events behavior.
Leif: I sent a text last Friday to www-style. Look for my name or for
hit testing.
<glazou> http://www.w3.org/mid/op.vhqsajuxtmo5g6@nynorsk
<tantek> http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html
Leif: I used Dean Jackson's spec. Mine has more comments.
<tantek> http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-events-20100820.html
Bert: Would all kinds of pointer event be handled the same, or is there
different behavior for e.g., left click and right click?
Tantek: No, all the same way.
Tantek: I was planning to put 'pointer-events' in UI module and make it LC.
Leif: Yes, that was my idea as well.
Tantek: I want to make that module smaller, with only what has two impls.
Anne: It is not currently in that module.
Tantek: Right, I want to add it.
Leif: Is that too quick? There is no good draft yet. Main interest for us
is to have the same default behavior, less to have a property.
Tantek: Would Opera be able to change its behavior.
Leif: Yes, we would like to simplify.
Anne: Some east-asian sites especially seem to rely heavily on IE's behavior.
Anne: Gecko seems to have bug as well.
dbaron: Yes, a known bug. No fix planned right now.
dbaron: If there were a spec, we might be more willing to change behavior.
<anne5> https://bugzilla.mozilla.org/show_bug.cgi?id=102695
Tantek: So my new proposal is to put it in UI module, marked as "at risk"
so that we can pull it easily before PR.
dbaron: I want to get Robert O'Callahan's opinion.
Anne: Need to define what element corresponds to (x,y) on the screen.
David: The Firefox bug doesn't seem to get a lot of duplicates, so not
a big problem at the moment.
Tantek: I'll put in some simple prose absed on Dean's draft then. Until
I hear more from you or from Arron's test.
glazou: UI is not in our *current* charter. Can we publish an update
nevertheless?
Fantasai: A charter revision is possible, but since we're rechartering
in a few months...
Tantek: OK, I'll just work on the editor's draft and prepare it for LC.
Tantek: Can still receive comments on it.
[Discussion about speeding up the rechartering. Could recharter earlier,
but then we can't put CSS2.1 in it as "finished"...]
Chris: We'd need good text about CSS2 if we recharter early.
glazou: That's doable.
glazou: We already said Chris, Bert, Peter and me would work on charter
in next three weeks.
04:08 -!- Zakim [rrs-bridgg@128.30.52.169] has joined #CSS
RESOLUTION: try and move AC review of charter forward, to get UI module
in it and publish a LC asap.
<tantek> send new charter to AC by the end of September, with 4 weeks
review, should be complete by end of October (in time for TPAC)
Chris: We should inform SVG of the planned work.
ACTION chrisl: tell SVG about planned work on pointer-events in CSS WG.
<trackbot> Created ACTION-258
Styling Attribute Syntax
------------------------
Publish as CR?
<tantek> http://dev.w3.org/csswg/css-style-attr/
Tantek: What did the exponent issue have to do with this draft?
Chris: CSS2 doesn't have scientific notation, so style attribute doesn't
have it either. So SVG asked about that.
fantasai: But is that an issue with this draft?
Anne: Style attrib draft can refer to CSS latest state, not necessarily
CSS 2.1.
fantasai: Draft links to core grammar, which doesn't change anyway.
<howcome> font-size: 2.6e-4em
<TabAtkins> font-size: .00026em
<TabAtkins> What's the difference?
Tantek: Where in the style draft is the restriction?
[Old discussion about scientific notation not needed.]
David: style attr should not have a different grammar than full CSS.
Chris: If you rewrite a stylistic attribute to a style attribute, you
need to be able to allow everything.
<dsinger> viewport-width 1.27e11 cm
dbaron: This draft is not the place to change CSS.
Fantasai: The draft carefully points to just the core grammar, nothing
that restricts the attribute value to CSS2
glazou: Draft cannot refer to documents that aren't CR, if it is to
become CR or better itself.
Tantek: Can Chris show the specific text to change?
Tantek: This can go to CR as is.
Tantek: If CSS's core grammar is revised, we can just make a quick
revsion of the style attribute spec.
fantasai: Changing the core grammar isn't not likely to happen anytime
soon anyway. If it changes, we can update the style attr spec.
glazou: Objections to CR?
RESOLUTION: publish style attr as CR.
<br type="lunch" />
<howcome> Frank, who some of you met during lunch is responsible for
specification documentation for Opera. Here are his documents
http://www.opera.com/docs/specs/presto26/
CSSWG Charter cont.
-------------------
Scribe: TabAtkins
glazou: I'd like to come back to the charter for a bit.
glazou: Anne, what is the status/priority of the two specs you own?
CSSOM and CSSOM View.
anne5: View is still somewhat in flux, but getting progressively better.
anne5: There have been requests for new features. Hixie wanted
scrollIntoView(), for example. Also a few other legacy properties.
anne5: It also has the Media Query api.
anne5: Overall it's still in flux, but it's being implemented.
glazou: So View remains in the charter, medium priority.
glazou: And CSSOM?
anne5: I thought I'd poll again recently to make sure there was value in
the the Value API.
anne5: It hasn't ever been published as a WD, but it's in the charter.
It's still got a lot of red boxes.
anne5: It's pretty high priority for me personally; it has a lot of
necessary stuff.
anne5: It does value serialization, getComputedStyle(), etc.
anne5: For the Value API, I just need to invent something and hope
it's good enough.
glazou: So keep it in the charter, at medium priority.
Media Queries
-------------
anne5: After MQ was done, I thought about defining MQ2, which defines
both the query and the types so it can be truly standalone.
anne5: Right now it depends on CSS2.1 and HTML4 for the definitions
of several types.
fantasai: That sounds like basically an editorial issue.
glazou: So, next issue is MQ - issues, test suite, further steps.
glazou: Anne, what's the status?
anne5: I think I sent an email with my issues.
<anne5> http://lists.w3.org/Archives/Public/www-style/2010Jul/0448.html
anne5: With the test suite, there are a few things. For one, it uses
something moz-specific.
ChrisL: What does it use?
anne5: -moz-initial for font sizes. I guess we can just remove it
and use 16px.
anne5: color-index doesn't appear to be implemented much.
dbaron: The spec says that color-index should only work if you have
an indexed-color device.
dbaron: Which we don't support, so we always return false.
ChrisL: Are there any impls that support a 256-color device?
anne5: Personally I don't really know what the feature means or does.
ChrisL: [explains color-indexed displays]
ChrisL: Basically there's nothing *left* to test this on. All the
devices it could apply to are long past obsolete, like a
black and white tty device that CSS also talks about supporting.
TabAtkins: Can we just drop this, then, since nobody actually needs
it and we can't do a non-trivial test?
anne5: We could, but we have to go through LC again.
ChrisL: I don't think there's a decent reason to drop it.
anne5: So let's keep it then.
anne5: Do we have guidelines for what the sourcecode of the tests
should look like?
ChrisL: Given that it's a single page, [something about the way the
test displays results].
dbaron: We could change the javascript up a bit to make it easier.
anne5: We'll have two complete implementations very soon.
ChrisL: So we can get an impl report out of it moderately easy?
dbaron: Yeah, and we can tweak it if necessary.
glazou: How many people reviewed these tests?
anne5: dbaron wrote them and I reviewed them.
glazou: On my Mac, safari is more fail than pass. All green on Firefox.
<glazou> http://www.w3.org/Style/CSS/Test/MediaQueries/20100726/media-queries-test.html
glazou: ETA for all green on Opera?
anne5: It's all parsing failures. I can push it, but otherwise it's
sorta near future.
<anne5> http://dev.w3.org/csswg/css3-mediaqueries/
<oyvind> (also missing support for dpcm)
glazou: Next steps? When can we move?
glazou: So we just need implementation reports.
anne5: I guess let's leave the tests as beta until we have one more
implementation, then we'll push it as final.
anne5: Then we can go to PR.
arronei: Do we want a deadline set for reviewing?
anne5: Nah, just fix the bugs. Reviewing should just happen at the same time.
CSS Snapshot 2010
-----------------
RESOLVED: 2010 Snapshot is 2007 Snapshot + MQ.
howcome: I think B&B should go in the snapshot.
fantasai: We need to wait for a test suite for it. It'll probably go
into 2011.
<fantasai> also, the spec isn't as stable as MQ either
Selector Serialization
----------------------
glazou: Next topic, selector serialization.
<anne5> http://lists.w3.org/Archives/Public/www-style/2010May/att-0372/SSEL.html
<anne5> http://lists.w3.org/Archives/Public/www-style/2010May/0372.html
anne5: I don't have a problem with rewriting it; I'm not entirely certain
I like this structure.
glazou: It's just editorial work making it more coherent with how we
describe selectors in the Selectors spec.
<dbaron> my comments were http://lists.w3.org/Archives/Public/www-style/2010Apr/0452.html
<dbaron> Tab's comments were http://lists.w3.org/Archives/Public/www-style/2010Apr/0382.html
anne5: Ideally, I think serializing selectors and some hook into parsing
a selector would go into the Selectors spec.
glazou: Is that more relevant to the selectorText attribute in the CSSOM?
anne5: There might be other things that need to use the serialization.
anne5: Parsing and serializing seems like critical infrastructure that
should be in the core spec.
glazou: That would require moving Selectors in the priority part of the
charter.
TabAtkins: Didn't we put Selectors 4 in Low Priority?
glazou: Not yet. We can.
<anne5> (I didn't address your comment TabAtkins on selector serialization
if you mean that.)
Bert: I don't think we need another Selectors spec; second, selectors
isn't about parsing or serializing.
fantasai: If you don't implement the DOM, the conformance criteria
should say that the OM stuff doesn't apply to you.
<anne5> (I deferred them hoping for what we just agreed to :))
glazou: We agreed to dispatch OM sections to individual drafts. We
absolutely need OM improvements - it's the worst part of CSS
right now.
glazou: Since it's only serialization, not new selectors, it can just
be a revision.
tantek: There'll be new selectors in CSS3 UI.
fantasai: You might want to split that into a separate "UI Selectors"
spec, so thinks like QuerySelector can refer to it without
depending on all of UI.
Flexbox
-------
Scribe: fantasai
glazou: Next topic, Flexbox!
<anne5> yay flexbox
alexmog: We have an old spec and a new proposal; we have a number of
very specific issues in the tracker I've opened which apply
to either proposal.
alexmog: Should we discuss where the spec is going, or the issues?
dbaron: Additive flex is important to us
Tab: I have several options for representing additive flex in addition
to absolute flex
Alex: There should be a very simple mapping from the old spec behavior
to the new spec behavior
Tab: One option is to have an additive flex unit
Alex: One thing I liked about the old spec is that it's really really simple
Alex: And it's exactly what you need for building UI
Alex: Office UI is built with something similar to flexbox, or maybe
even simpler than that.
Alex: You can get lots of pieces built by different people put together
in a coherent way only if the behavior is really simple.
Alex: Don't want interactions with other things, margin collapsing, etc.
Alex: I really liked the simplicity, and also the isolation from
everything else
Alex: The ability add a new module that adds really useful algorithms
without complexifying everything else.
Tab: All it's essentially doing is taking the abilities in the current
draft, and generalizing them slightly.
Tab: There's no interaction outside the flexbox container.
dbaron: What happens to flex units outside a flexbox?
Tab: It would have to default to something. Haven't figured that out yet.
dbaron: That's a concern I have is that the flex units leak out
Alex: There's a temptation to apply flex units outside the flexbox model
dbaron: e.g. flex margins in abspos
Tab: We totally want that
Alex: I would like to come up with Grid very soon. If you look at ...
Grid and Flexbox play together very nicely.
Alex: I would hope that other layout models interoperate with flexbox as well.
Tab: you can have flexboxes spill into multiple lines, sortof like a table
dbaron: XUL has a grid model, but it's not in the flexbox spec
Tab: You could do a XUL-type grid in flexbox easily
Tab: You could also use flex concepts in Template Layout, where it would
be very useful.
howcome: I'm hesitant to define units that are only useful within a
specific layout algorithm
<TabAtkins>
http://www.xanthir.com/document/document.php?id=615d486a4dd75e8f4ae644eaa02af778211809483881e4964e66c29d5618b7ae457190b450c9e53abee05aa2e590cefc8100663c8d91328a1bd786ab9f1e7f2b
fantasai: You'd want to specify exactly which properties accept
flex. e.g. text-indent should not take flex units
<dbaron> text-indent flex would be like text-align-first: end
<Bert> (Me thinks, on the contrary, a fexible text-indent would be
very nice: can have the last line of the para flush with the
right margin that way... :-) )
Alex: I considered having Grid do layout computations similar to flexbox
Alex: .. specify width of multiple columns, without defining some kind
of flex unit
Alex: Also it would be useful for flex units to not complicate ...
Alex: Maybe there is a compromise where there is a flex unit that can
be parsed into a grid unit, but can't be parsed into a length.
Alex: Currently in grid positioning, there is an fr unit that only
applies to that feature
Tab: I want to apply flex to margin/border/padding/width/height
Alex: maybe you could have a different property that specifies a
flexible margin
Tab: I don't think it makes sense to add ... to avoid having flex
units in the margin
Alex: margin is a way for flexbox to spill outside the flexbox
Tab: The use of flexes is only defined within the context of flexbox.
Alex: ... isolation.
Tab: If you were to use a flex unit outside a flexbox, it would
compute to a used value of zero
fantasai: or maybe even a computed value
Tab: I understand your concern about the application of flex to
normal flow, but I don't think it is actually a problem.
Alex: If that's the only thing we are disagreeing on, we're doing
pretty good.
Alex has some concerns about syntax of various properties
Tab: Could probably get a test impl in Webkit
dbaron: One other thought about the units is maybe we want some
other type of value within the property that's not a unit
<dbaron> could we do something like height: flex(1) [non-additive]
or height: 50px flex(1) [additive] ?
Alex: I would prefer that slightly over a general unit
Alex: It's obviously not a length
Alex: It's something specific
Alex suggests adding an additional set of margin properties for
flexible margins
fantasai points out that this is a cascading nightmare, and would
be confusing to authors because they would think they're
resetting margins (e.g. to zero) when they've only reset
one set of margin properties, the other set of which still
has some other values
* fantasai is strongly against a new set of properties for margin therefore
<TabAtkins> http://www.w3.org/Style/CSS/Tracker/issues/open
ISSUE-138: http://www.w3.org/Style/CSS/Tracker/issues/138
Tab: Is this similar to the way abspos inside tables is handled?
Alex explains the proposal
fantasai: yeah, that's just like tables
dbaron: We've institutionalized placeholders now.
Tab: It makes me sad, but yeah.
RESOLVED: Out-of-flow elements use placeholders during flexbox construction
ISSUE-139: http://www.w3.org/Style/CSS/Tracker/issues/139
Alex: Next issue is what reversing pack: start does
dbaron: The whole pack-align-direction stuff is probably one of the
more confusing things in the current spec
dbaron: The current proposal still has box-direction?
Tab: It does have display: flex
Tab: and it does have direction. It takes two directions, one for
the main flow
Tab: Another for which side they're placed on
fantasai: So you have like an inline-progression-direction and a
block-progression-direction
dbaron: how do you justify the boxes in the transverse direction?
Tab: You give all the boxes a flex of one
Tab: auto heights and widths evaluate to one flex on flexbox
dbaron: In transverse direction?
Tab: yes
dbaron: ok, that solves it
ISSUE-140: http://www.w3.org/Style/CSS/Tracker/issues/140
dbaron: min/max widths assign intrinsic widths, rather than assigning
constraints
dbaron: in Mozilla's implementation
Alex: At which point do you apply min/max height?
Alex: in the primary direction, I thin it should have its normal meaning
Alex: So we've run all of the normal algorithms
Alex: And then max it with max-width and height, redistributing
available space if necessary
dbaron: Which is the same problem you'd have with height in a
fixed-height environment
Tab: Horizontal flexbox, max-height on one of the flexbox children,
and box-align: stretch.
dbaron: Ah, the table problem
Tab: And one of the children is taller than the max-heights
Tab: Everyone wants to stretch to the height of that child
Tab: Do we honor the max-height, or do we ignore it
dbaron: Or shorten the parent
Alex: I think shrinking the parent is the worst option
dbaron: I think it's the best option
Tab: You wouldn't want to do that if box-align is start.
Tab: So it's really weird if we apply max-height to the flexbox parent
Alex: I prefer an approach where everything is normal, and whoever
chooses to have a max-height just becomes smaller
Alex: I don't think it matters where it aligns
Tab: It has to be defined
Tab: And I would like to control that
fantasai: So allow stretch + a direction
Alex: I prefer start being the default alignment
Tab talks about vertical alignment within the box
Bert suggests using 'vertical-align' just like in tables
fantasai: or flex the padding
fantasai: I'd suggest centering by default
discussion of directional terms
transverse direction and progression direction?
<Bert> (Tab's gestures suggest "wavelength" and "amplitude" :-) )
dbaron: I lean towards centering as well
JohnJansen: me too
Alex: But the contents align to the top by default
Alex: It looks odd to center the box, but top-align its content
Tab: Yeah, that makes sense
Tab: to keep those two consistent
RESOLVED: max-width/height restricts the size of a flexbox child
RESOLVED: If a box is shorter than its row, it is aligned as
if box-align: before.
ISSUE-141: http://www.w3.org/Style/CSS/Tracker/issues/141
Alex: Need to define the baseline of the flexbox
inline-blocks it's the bottom line
inline-table it's the first line of the first row
Alex: Should aligning contents of flexbox to the baseline align the
same way as table cells, or something different?
dbaron has a preference for copying inline-block
dbaron: Part of the reason inline-table works the way it does is
because vertical-align: baseline on table cells uses the
first line
dbaron: and given you're using the first line, you might as well
use the first row
Alex: The most common case for flexbox would be form controls
<Bert> (http://www.w3.org/TR/2002/WD-css3-linebox-20020515/#inline-box-align
allows to select which line is the line that determines the baseline.)
Alex: They will usually be only one line of flexboxes
Alex: but you do want baseline alignment
dbaron: You first line when you have a flexbox with a checkbox and
a multiline label fo rit
<dbaron> (or center, in which case you're not doing baseline
alignment at all)
Tab: So let's go with inline-table model
Alex: My implementation uses the first line of the first item
Alex: It's super simplistic, but I'm still looking for a case where
it wouldn't be a good choice
dbaron: the one case it might not be reasonable is if you have a
bunch of flexboxes that are baseline-aligned to each other,
but the first item isn't
Tab: In the current draft, the alignment has to be the same for all
flexobx children
dbaron: I guess that's not a problem then
<dbaron> except it is a problem in Tab's draft
<dbaron> since he uses vertical-align, which goes on children
Tab: But in my draft, you do vertical-alignment by applying
vertical-align to each flexbox individually
Alex: Do we agree on doing first line of first item?
Alex: And if we find cases where it's not a good choice we'll add them
<dbaron> (might want to check if any boxes have baseline alignment first)
<TabAtkins> http://www.w3.org/Style/CSS/Tracker/issues/142
<trackbot> ISSUE-142 -- Does box-ordinal-group change drawing order? -- open
<trackbot> http://www.w3.org/Style/CSS/Tracker/issues/142
Alex: So Appendix E
Alex: There is a few options
Alex: One is getting rearranged throught the ordinal group
Alex: either draw in source order or layout order
Alex: Argument in favor of layout order is that it's more visually expected
Alex: Minor inconvenience is it will need an update to appendix E
Alex: Other issue is if we get to 2D flexible grid
Alex: It is less clear what order to paint, and source order makes more sense
dbaron: I think Appendix E should refer to order in the box tree
dbaron: And I think box-ordinal-group should change order in the box tree
dbaron: so I think we're done
Alex: So let's use layout order
Tab: I think that's the right source, and ordinal-group should rearrange
the box tree
RESOLVED: Flexboxes drawn in layout order (as altered by ordinal-group).
Tab: I don't currently have ordinal-group in my draft. bz doesn't like it.
Are we still down with it?
dbaron: Our implementation is a little flaky. We only started using it
for really critical stuff in this Firefox release
Tab: His problem was that if you have a large group, you have to run
sorting algorithms on it
* Bert considers 'box-ordinal-group: alphabetic', good to make an index...
fantasai: Might want to note that authors should avoid doing that if
they want to avoid perf problems...
Alex: I imagine someone sorting icons in the filesystem by assining
filesize to box-ordinal-group...
<dbaron> issue-143?
<trackbot> ISSUE-143 -- Does "shrink-to-fit" width of a flexbox child
depend on available space? -- open
<trackbot> http://www.w3.org/Style/CSS/Tracker/issues/143
Alex: Is the pref width max by available, or not?
Alex: I believe in Mozilla it isn't
Alex: Given we're going to adjust that later with flex, it makes more
sense to lay out in infinite width
dbaron: The issue here seems to be that WebKit is using fit-content
where it should be using max-content
dbaron: I think we do want to use max-content
Tab: Ok, let's track Mozilla behavior here.
<dbaron> I can't really think of any use cases where this makes a big
difference other than the text-in-tables type issue
RESOLVED: Use max-content for preferred width in flexbox sizing
<dbaron> ISSUE-144?
<trackbot> ISSUE-144 -- distribution of negative available space -- open
<trackbot> http://www.w3.org/Style/CSS/Tracker/issues/144
Tab: How we distribute negative space.
Alex: currently, the exact same algorithm that is used for positive
space is applied to negative space just with a negative sign
Alex: So if an item has a bigger flexibility, meaning it's greedier
and wants to get more extra space available, then it will get
significantly less space if there is not enough space.
Alex: I'm having a hard time finding any situation where it's useful.
Alex: For example if you have a lot of text in one box and not much
text in the other, they'll balance in a way that's completely
non-intuitive
Tab explains some algorithm
dbaron: what if one has flex 1 and the other has flex 2
fantasai: I don't think the one that's supposed to be twice as wide
as the other should wind up half the size of the other
b/c we don't have enough space
... TeX
dsinger: You should study the TeX glue model
dsinger: Knuth solved this pretty solidly so you should go look at that
Alex: We should either ignore space when availspace is negative
Alex: and distribute some other way
Alex: Or have a separate value that is how to distribute when negative
dbaron: There are some cases where you want to distribute space in
proportion to its flex
dbaron: e.g. you have two groups of flexboxes, one with 4 children
and one with 2, and you want to distribute the extra space
evenly among all the grandchildren
dbaron draws a box with two boxes inside it
one of which has 2 boxes inside, the other of which has 4 inside
dbaron: In a case like this you do want to maintain flex ratio when
distributing negative space
Alex If you shrink, you want to shrink proportionally to the amount
of text ....
Tab: If the flex is proportional to their preferred widths.
Tab: When the flexes and preferred widths don't match, that's when
you get the non-intuitive results.
dbaron: Maybe completely ignoring flex is fine
<dbaron> (when shrinking)
Tab: And shrinking in proportion of their preferred widths is fine
<dbaron> ISSUE-145?
<trackbot> ISSUE-145 -- inline-block children of flexbox -- open
<trackbot> http://www.w3.org/Style/CSS/Tracker/issues/145
fantasai: The spec should say 'inline-level elements' and then it's
completely clear.
Tab: The spec groups inline elements together
Alex argues that inline-blocks should become individual items
dbaron: I think you at least want to group text and true inlines
Arron: whitespace?
Tab: just like tables
Alex: I want a model where flexbox with a bunch of buttons in it
doesn't require display:flex on all the buttons
dbaron: I'd be fine with saying that you'd only wrap text and
*non-replaced* inlines.
fantasai: Ok, so you want atomic inline-level elements to get
individually wrapped, and non-replaced inlines get grouped
CSS2.1 Issues
-------------
fantasai: Issues 158, 159, and an unnumbered issue are all about
margins and clearance.
The original issue that caused this was issue 6.
TabAtkins: We really need to talk to Michael (Arron's coworker)
about this.
ACTION arron: Talk to coworker about proposed clearance changes.
<trackbot> Created ACTION-260
<fantasai> http://wiki.csswg.org/spec/css2.1#issue-158
fantasai: Info about these issues was sent to the list.
<fantasai> with proposal http://lists.w3.org/Archives/Public/www-style/2010Aug/0458.html
<fantasai> http://wiki.csswg.org/spec/css2.1#issue-159
<fantasai> with proposal http://lists.w3.org/Archives/Public/www-style/2010Aug/0391.html
<fantasai> 158 and 159 should be editorial
<fantasai> http://wiki.csswg.org/spec/css2.1#issue-195
<fantasai> back to 195
<fantasai> http://lists.w3.org/Archives/Public/www-style/2010Aug/0462.html
dbaron: For issue 195, you could maybe say it divides it into two pieces,
one on either side of the block?
Bert: The original problem was if one side was empty, like
<span>foo<div>bar</div></span>. The new text doesn't seem
to clarify this yet.
Bert: Perhaps add an "even if either side is empty"?
fantasai: Sounds good to me.
TabAtkins: Sounds good.
RESOLVED: Proposal accepted for CSS2.1 Issue 195 with edit above.
fantasai: The other issue I editted was the bidi one.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2010Aug/0465.html
<fantasai> http://wiki.csswg.org/spec/css2.1#issue-187
TabAtkins: You have two possibilities in that proposal. Do you know
if either should be preferred for compat reasons?
Bert: The "atomic inline" one seems easier.
fantasai: One wrinkle is that if you replace an image with its alt text,
the bidi ordering may change. The more complex first option
takes care of that and prevents it from changing.
Bert: I'm not sure I understand what the "replaced element that would
be inline if not replaced" means.
TabAtkins: An image, for example, will be replaced by ordinary alt
text if not available.
fantasai: The wording is to deal with the case for when you can have
either text or a replaced element. If you set an explicit
embedding level and there's text, then the surrounding
content will be affected by the direction of the embedding.
If it's a replaced element and you define replaced elemenets
to be neutral, though, then the replaced element won't have
the directionality from the embed.
fantasai: So now if you set unicode-bidi on the <img>, it'll affect
how the surrounding text is ordered, in the same way
regardless of whether it's a replaced element (image) or
not (text).
Bert: There's a parenthetical about run-ins?
fantasai: That's why the wording is so weird, specifically to handle
runins, or else I'd just say elements with display:inline.
fantasai: It seems that no one disagrees in principle with this,
they're just confused by the wording?
Bert: It's very confusing.
arronei: Agreed.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2010Aug/0448.html
szilles: I thought of a problem with my suggested fix for issue 198,
but I can't recall it exactly right now.
ACTION Steve: Respond to yourself about issue 198.
<trackbot> Created ACTION-261
Multicol
--------
howcome: Multicol moved into CR and has 6 implementations!
howcome: They have a baseline level of compatibility.
fantasai: Probably pagination issues will be the worst.
howcome: What I'd like to spend time on is to fix two problems in the spec.
howcome: 1) We don't really define how column rules behave when the
content doesn't fit nicely.
howcome: 2) We copied the border-style values from the border property,
but some of them don't make a lot of sense in terms of
columnn rules.
howcome: double/solid/dashed/dotted/none make sense. I don't know about hidden.
dbaron: hidden only exists for the collapsing border model in tables.
howcome: I think we should remove inset and outset.
howcome: They come from buttons for a pseudo-3d effect. But with
columns you don't have that.
glazou: I don't think we should remove values because otherwise you lose
consistency with border-style
fantasai: You should make it work like the collapsed borders model
and treat them like ridge and groove.
dbaron: Except that we got the spec backwards in collapsed borders years ago.
<dbaron> actually border collapse is the right way round
fantasai: I think that inset/outset it isn't clear what's supposed
to happen, so just go copy what the border-collapse thing does.
howcome: That's an easy solution.
RESOLVED: Use border-collapse border-style behavior for column rules.
howcome: Next issue is column rules. They're drawn between columns, and
are the currently the height of the multicol element.
howcome: So even if something overflows, you don't have column rules
going down to it.
howcome: I think that if we extend, we don't want individual rules to
extend individually.
howcome: But then you have long column rules sticking out the bottom for
seemingly no reason in the rest of the multicol.
howcome: Also, there's a question of if you should draw rules between
columns that that overflow the multicol horizontally.
howcome: Robert argues on the list that you should treat them the same.
howcome: But also maybe it looks more elegant to keep the rules horizontally.
[everyone agrees that it looks better to show them horizontally, cut
them vertically]
howcome: Also, what if people make column rules that are super wide
and would overflow the content?
[agreement that authors should be allowed to do that if they feel like
it, don't try to clip]
RESOLVED: Column rules are not clipped by the multicol element horizontally.
fantasai: What's the stacking order for column rules?
<fantasai> s/just above the background/immediately below the border
(above the background)/
howcome: Cool.
alexmog: If you had only two columns, there'd only be one rule and
nothing outside the box (in your example)?
howcome: Yes.
szilles: If it's balanced columns in an element with sufficient height
that there's a gap at the bottom of each column, does the
rule extend all the way to the bottom of the multicol, or
only to the bottom of the content?
howcome: The spec says to make them the full height.
[agreement, looks good]
howcome: though I think we might want to add border-clip ability to
rules at some point
[agreement]
alexmog: Word doesn't extend it to the bottom of the element, but
we can use height:auto to simulate the behavior, so we're okay.
RESOLVED: column rules are drawn to the height of the multicol element
howcome: Also, rules are only generated between columns with content.
If the element is wide enough to hold 5 columns, but there's
only enough text to fill 2, only a single rule is generated.
<Bert> ISSUE-129?
<trackbot> ISSUE-129 -- balanced columns in fixed-height -- open
<trackbot> http://www.w3.org/Style/CSS/Tracker/issues/129
howcome: [draws a diagram with 3 columns. An h2 is col-span:all in
the middle, with text above and below it.]
alexmog: Conceptually, the text above the h2 comes before it in the
source, text below it is after it in the source.
alexmog: Now what if you have even more content, so you have overflow
columns, and another h2 with col-span:all in that section?
dbaron: Maybe col-span:all should be cancelled on overflow sections?
alexmog: If you say that setting overflow makes new columns to the
right, *unless* it's balanced and doesn't fit, that's an
interdependency.
alexmog: If the content fits and there's extra space, extra space is
distributed betweeen columns. If there's not enough space,
there's no balance - it just fills what it needs and overflows.
fantasai: I don't know if I like that.
[pagination discussion - how multicols work in paged media]
dbaron: Why do we allow column balancing in a fixed-height container?
howcome: I think it looks nice.
alexmog: You might have a paged implementation where you want to
balance the last page.
howcome: Also if you have a min-height or max-height, it could
suddenly stop balancing because the content got too large.
[back to colspan discussion]
[colspan gets turned off if the element is in an overflow situation]
dbaron: That content ordering is crazy. Would anyone ever want that?
dbaron: I'm also not sure it makes sense to have a colspan on in fixed
height columns.
alexmog: It makes lots of sense in a paged situation.
* Bert thinks 'div.article {overflow: auto; overflow-style: paginate}' --
makes flippable pages, instead of a scrollbar or something else
continuous.
howcome: I propose we go with alex's suggestion. col-span:all only
spans the visible column, and colspans in an overflow column
don't colspan.
dbaron: What I want to say is that colspan doesn't do anything if your
column is fixed height.
dbaron: The case where you're actually doing fixed-height columns,
you're not wanting actual colspans.
TabAtkins: What about paged media?
dbaron: I'm distinguishing fixed height from paged media. They work
differently, and won't cause a problem.
fantasai: How about columns overflow downwards?
TabAtkins: In multiples of the original height!
fantasai: But an original use-case was specifically to flow columns sideways.
fantasai: And we resolved on that.
TabAtkins: Maybe a property at some point to specify how multicols should
place their overflow columns.
szilles: And that solves dbaron's issue, I believe, if you overflow them
downwards in a "paged" fashion.
dbaron: Yeah.
howcome: I think we don't want to add anything for the vertical overflow
yet. We'll just go with alex's proposal.
<dbaron> I still don't think anybody has shown any reasonable case that
would be disabled.
RESOLVED: Use Alex's suggestion for disabling colspan on elements located
in overflow columns.
Box-shadow
----------
<smfr> ooh maybe i should call in
+smfr over a sketchy telephone connection
<fantasai> http://dev.w3.org/csswg/css3-background/#the-box-shadow
<tantek> (phone rings)
dsinger: we want a note saying something about half the standard deviation
dsinger: as long as we don't talk about the edge of it
fantasai: I took some of the text and put it into an explanatory note -
visibly apparent color transition ... twice ... fully transparent
at the edge outside it.
tab: we're no longer referring to the edge of the blur because that doesn't
exist.
<fantasai> A non-zero blur distance indicates that the resulting shadow
should be blurred, such as by a Gaussian filter. The exact
algorithm is not defined; however the resulting shadow must
approximate (with each pixel being within 5% of its expected
value) the image that would be generated by applying to the
shadow a Gaussian blur with a standard deviation equal to
half the blur radius
<fantasai> Note this means for a long, straight shadow edge, the blur
radius will create a visibly apparent color transition
approximately the twice length of the blur radius that is
perpendicular to and centered on the shadow's edge, and that
ranges from the full shadow color at the endpoint inside the
shadow to fully transparent at the endpoint outside it.
tab: ... two standard deviations and that's really easy
tab: at the blur radius ... 97%
q&a between jdagget and tabatkins
<smfr> this phone is terrible
<smfr> i'm fine with the current spec btw
tab: 97% isn't even the point where it hits 100% transparent but I've
found thru experimentation, the difference between those two is
pretty big, to the point where the shadow looks smaller than it should.
<dsinger_> I think 2*sigma is actually 95%
tab: if you want the shadow to extend out....
<fantasai> visibly by the amount of the blur radius
* dsinger_ see 'standard deviation and confidence intervals' at
http://en.wikipedia.org/wiki/Normal_distribution
tab: dsinger you're right, 95% lies between both sides, but in this,
we're looking only at one side which is ~97% from there
fantasai: if everybody is happy with current text we can resolve this issue
jdaggett - it may affect pixels beyond
tab: it will
dsinger: if I'm running on a 16 bit system...
tab: but even there, you won't be able to see ...
jdaggett - I would watch that assertion - with the right color and
background you will see it for a long way
jdaggett - if you have issues where the surrounding geometry is very
distinguishable, you'll be able to see it more.
szilles: isn't this an implementation issue?
tab: within the bounds it is safe to drop to full transparency at that
point. if you wanted to you can do that. it's just not required.
<anne5> http://dev.w3.org/csswg/css3-background/#the-box-shadow
(skype discussion for getting another person on the phone)
<smfr> don't they have conference calls in norway?
<anne5> we use telepathy here
<glazou> vikings use empty bottles of aquavit only
(bert sets up zakim)
(static on phone, laughter)
<smfr> btw i have to leave early again
+bradk over sketchy telephone connection
fantasai: we have another topic, which is the stacking order of the
inset shadows
fantasai: the proposal that came in was that the inset shadows should
be painted *above* replaced content, so we asked why not
all content to be consistent
fantasai: the proposal is to paint the inset shadows above the content
layer, but not z-index things
dbaron: so if you have an inner box shadow it overlaps the text in
the box?
fantasai, tab: yes
dbaron: ok
<smfr> i don't like this proposal
<smfr> it has stacking context implications
fantasai: the z-index lets you pop things out and bring them forward
tabatkins: children with a higher z-index are painted above
dbaron: you want to say it in terms of [CSS21] appendix E, not in terms
of z-index
<smfr> agreed
fantasai: it's a lot of layers so you need something more precise
fantasai: it's between layers 8 and 9
dbaron: you don't want to say it that way either
<smfr> http://www.w3.org/TR/CSS2/zindex.html
fantasai: 8 & 9 in the sublist of 7
fantasai: not it is top level 8 & 9 - not sublist
<smfr> so does an inset shadow make the element a stacking context?
dbaron: we need a new top level paint layer for inset box shadows
dbaron: if you put it above rel-pos things, it's not just above
rel-pos things in that element, but also above rel-pos things in ....
dbaron: that top level list is what to do for each stacking context
dbaron: for each stacking context you paint ... i'm trying to think
about what this means
<bradk> My connetion is bad, but would it be possible to only paint
above the content when there is non-visible clipping?
dbaron and fantasai discuss
<bradk> That would also make it look best with things that protrude
outside due to negative margin, etc.
fantasai: where is a block child painted ... here....
<smfr> so if you paint the shadow above the content, think about what
things look like with overflow
<smfr> borders draw under the content
dbaron: you can stick it in point 3 or 4 in sublist 7
<smfr> if the shadow draws on top, it's just weird
<smfr> gonna drop off the phone; it's useless
<smfr> also, doesn't this mean that the inset shadow draws above the border?
<fantasai> So the proposal is to paint inset shadows immediately
below the outline.
<fantasai> And yes, this would have the side-effect of drawing the
shadow above a border-image
<smfr> i think this is weird
<fantasai> (since it will never overlap with the border)
<smfr> i think the shadow should be between the background and the border
<dbaron> sylvaing, Zakim bridge?
tab: if you're having the border-image extend into the box - that's
how it works
<smfr> if it's just under the outline, then you've lost the "pop out
with z-index" trick
<bradk> TThe call quality is like listening to a tin can
<smfr> so the shadow will draw over abs pos, z-index children, which
is also weird
tab: the point of having box-shadow back into the draft was having
something simple that we could accomplish now
<smfr> i'm with tab; we're making too many changes to box-shadow at this point
<bradk> smfr, can look good if you have light colored items inside a
scrollable box with inset shadow.
<dbaron> I'm with smfr
tab: "i'm with you you're wrong"
dbaron: I'd really like to get box-shadow unprefixed
dbaron: we're going to ship FF4 with box-shadow to indicate invalid
form fields, and authors are going to want to turn it off,
and they're not want to going to use a prefixed property to
do that
fantasai: So you either get inset shadows over the content, or you get
it under the border-image. You can't have both.
<smfr> yep
fantasai: Unless, perhaps, you have two different inset-ing keywords,
one which paints at one layer and one which paints at another.
<smfr> ugh
fantasai: and we could add the other keyword in CSS4 Backgrounds and Borders
tab: so no change to box-shadow now, but plans for v4 that will somehow
draw intelligently on top of content
<bradk> Overflow can be the trigger
<smfr> or wait for future filtery things
tab: overflow could be the trigger
tab: brad, could you explain what you mean?
brad: if overflow is the trigger, then if you have a scrolling box with
a shadow, then the content should be inside underneath... hello?
tab: .... --- .... ----
<smfr> i think interaction between different properties like that
should be discouraged
<sylvaing> it sounds like we're trying to make inset more 'realistic'
and I'm not sure why it should be more so than other aspects
of the feature
brad: when i did an experiment with box-shadow on a scrolling box
brad: it looks kind of strange to have the shadows behind the content and
scrolled out of view - it just doesn't seem natural
tab: this might be trying to make box-shadow too realistic
tab: in the mean time we do nothing. we recognize the use-case, but not
with box-shadow
<sylvaing> agrees with tab; if we want realism the feature already has
many shortcomings
tab: inset box-shadows above the background layer - what they do now,
below the content
<TabAtkins> I think that the above-content shadow makes scrolling look
a lot better, but I don't think it's a good trigger for the
new shadow. I don't like that kind of interconnection.
Also, it won't solve the basic problem of images.
<sylvaing> unclear why inset needs to be more real than the rest
<TabAtkins> Agreed, sylvaing.
<sylvaing> is comfortable with a simple decorative effect
fantasai: they are using it for glowy effects, lightbox
<sylvaing> but is not a designer either. argh.
<TabAtkins> I think we're best off by saying "We'll solve this
*properly* with filter effects; box-shadow is
supposed to be really simple"
<bradk> It is not so much that I want super realisom, it is that
scrolling things outside the box tends to destroy the effect
of it being a rectangle cut out of the canvas.
<bradk> It really looks pretty weird when you do that, IMO
<fantasai> bradk: if it paints over the content, it has to paint
over the border-image
<fantasai> bradk: so there's an unfortunate tradeoff here
<bradk> Agreed it is unfortunate. But in my way, it would be
limited to when you have overflow:[not visible]
<bradk> And that can be turned on and off for a lot of content
without much other noticiable effect
<fantasai> bradk: I think we have consensus that that kind of
out-of-left-field trigger is a bad idea
<fantasai> bradk: If we want a trigger, it should be in the
box-shadow property itself
(tab makes an example)
tab: scrolling with a box-shadow does look bad
tab: oh wait - it's fine
tab: this is right, the shadow shouldn't scroll
<bradk> It's just that, with overflow:scroll, for instance,
that it almost always looks wrong, unless all the
content is black.
<TabAtkins> data:text/html,<!doctype html><div style="width: 100px; height: 100px; -webkit-box-shadow: inset 5px 5px 10px
black; overflow:scroll; color:red;">foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo
foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo</div>
<TabAtkins> fantasai: I think Brad's right - it will look bad
in a *lot* of cases.
<anne5> (WebKit only does box-shadow prefixed)
fantasai: then we have the implementation issue that people
want to drop prefixes
<sylvaing> it looks bad in a lot of other cases too
<bradk> Now make even bigger blurrier shadows in that example...
<sylvaing> e.g. when background-color is transparent and you
can't see the shadow underneath but can see the
body background-color
Håkon introduces David of Opera who is implementing box-shadow
<sylvaing> the feature already has a very limited scope
David: I think I agree with what you're saying
David: we should leave box-shadow as it is
<sylvaing> yet there is no doubt that it already is useful to authors
<TabAtkins> sylvaing: Yeah, I think that's the thing. Sure,
it's rarely useful as-is, but you can't fix it
*properly* without a lot of work.
<anne5> (Opera currently does box-shadow unprefixed)
<bradk> What is the downsde of an overflow trigger?
tab: with scrolling it looks really bad, but ehhh, doing it
properly - there's more cases that can be relatively
common, that will also look bad, and we'll also have
to do more stuff to make them look good.
<anne5> (Gecko prefixed)
tab: with repairing this issue, a majority of things will
still look bad with inset box-shadows
<sylvaing> tab, yes. I too wish it were more useful than
adding a shadow to a custom button control and
the like. but it turns out that as simplistic
as it may be, it is very useful. we might already
have 80% of the feature.
tab: that's just how it is, we'll do it properly later
<bradk> Just limits border-image in overflow inset-shadow
situations, as upposed to all overflow inset-shadow
situations looking weird
fantasai: we can put both definitions in the spec, with
different keywords and mark them both at risk.
<fantasai> we mark both inset and inner shadows as at risk
<bradk> Then you could properly fix it for border-image
later and have a good default now?
tab: acceptable to you dbaron?
tab: add another keyword for the additional behavior and
mark it at risk
dbaron: i'd rather not keep adding stuff
<smfr> i don't want a new keyword at all
dbaron: two years ago we wanted to be done
<sylvaing> agree with dbaron and smfr
<tantek> we can always add a new keyword later if someone
has a solid proposal
fantasai: we have a solid proposal
fantasai: what you want to do to make everything look supercool
is to put content on the shadow and border-image and ...
tab: hopefully someday filters will let us do this (like IE4 filters? ;) )
tab: we want something like that
<bradk> That might be supercool, but I'd settle for reasonable
in the majority use cases
<tantek>: URL for said solid proposal?
<fantasai> Proposal is to have an 'inset-overlay' keyword that
behaves just like the 'inset' keyword except the
shadows it generates paint immediately underneath
the outline layer (when it is not painted at the
#10 option in Appendix E)
<fantasai> RRSAgent: pointer
<RRSAgent> See http://www.w3.org/2010/08/24-CSS-irc#T15-23-35
<fantasai> there's your url
<tantek> so noted
tab: that's what we want to do
fantasai: nothing right now?
tab: nothing right now
håkon: let's go to CR
<Ms2ger> Håkon++
<bradk> I'm hearing that 'inset-overlay' would be "at-risk"
(code for "never to be implemented")
<sylvaing> howcome++; this is about adding a simple shadow to
that facebook dialog that confirms you have given
up on all your privacy (again). Not accurate 3D
rendering of the stacking context based on the
sun's position. Ship it !
<bradk> True?
<TabAtkins> bradk: No, we're just not going to do it at all right now.
* TabAtkins wants a physically accurate rendering based on the
simulated position of the sun. Using geolocation.
<bradk> It is really only in overflow situations that it bothers me,
and then almost always in those situations
* sylvaing yeah, well. bite me.
<bradk> Come on, I'm not asking for ray tracing
* dbaron reminds TabAtkins that that requires geolocation,
gravitometer, and compass :-P
(slightly more furious typing)
Bert: so is the resolution CR?
Bert: I'm waiting for the chair
* sylvaing lives in Seattle, where shadows are a completely abstract concept
<bradk> Well and in some replaced objects too
glazman: absolutely
RESOLVED: publish as CR
<TabAtkins> bradk, I know, but it's still a decent chunk of complexity.
And we really want B&B to go CR.
<TabAtkins> bradk, B&B4!
<bradk> OK. What about images? As is on those too?
<fantasai> images are no different than other content
<bradk> OK with me
CSS Filters
-----------
dbaron: we might want a work item in the charter for some sort of a
filters spec
fantasai: that would be something with the SVG folks
fantasai: maybe make them primarily responsible for that?
* smfr has an action item for public-fx to draft a filters spec
RESOLVED: add filters spec to charter, as a joint item with SVG
glazman: how should we name that?
<bradk> on rectangular images with no alpha channel, you can't see
the inner shadow. Minor limitation. OK.
szilles: i have to raise an objection unless it is specified more
closely than that
fantasai: the application of SVG filters to CSS
dbaron: making SVG filters usable for CSS
szilles: I'm ok with what dbaron said
(cross talk)
glazman: what should we name it?
fantasai: CSS filters?
<bradk> Extended visual effects?
glazman: ok
<fantasai> CSS Filter Effects
håkon: the idea is to use SVG syntax?
dbaron: I think we may want a more CSS like syntax for it
dbaron: we need better notions of CSS layers
dbaron: SVG has notion of using fill or stroke as input to the filter
dbaron: we need content, or border, or background as inputs to a filter
<smfr> i anticipate some "convenience" properties for common filters
tab: yes we want to do that
Tab: That was the whole point of Brad's presentation at tpac
tab: at least for the canned filter effects, we want a convenient
syntax for it
<bradk> yep
bert: url()
tab: I don't want that
fantasai: you still have to type the input
bert: that's what the web is for , URLs
<smfr> div { filter: blur(10px); }
tab: I don't want to type URLs!
<smfr> or div { blur: 10px; }
<fantasai> no
<bradk> I agree with tab
dsinger: let's table this argument
bert: i object to reinventing the wheel
(syntax bikeshed)
glazman: we are not going to discuss this now
<smfr> gtg
-smfr
dsinger: once we have a editor's draft we can then argue
<sylvaing> i don't object to reinventing bert
glazman: we can close this topic now
F2F Scheduling
--------------
glazman: next meeting in Lyon in November
glazman: dbaron proposed to host next meeting after that in Mozilla
in Mountain View
glazman: March
szilles: we also need summer
glazman: june or august?
<anne5> is http://software.hixie.ch/utilities/js/live-dom-viewer/saved/596
a bug in Firefox?
<anne5> I think it's https://bugzilla.mozilla.org/show_bug.cgi?id=319729
* anne5 added a comment with the above test
szilles: tpac will be in oct or nov and not in europe
dbaron: boston in november is not that bad
glazman: we still need one between tpac and moz
jdaggett: proposal, it would be really good to get a set of people in Japan
<sylvaing> thinks we are due to host and strongly suggests august
<sylvaing> but definitely prefers Japan :)
dbaron: march, june or august? i don't know.
tab: bay area is great in june
dbaron: maybe we shouldn't sched too much for the weather
<bradk> +1 for bay area
<sylvaing> dbaron: weather is important so we can show seattle people
what a shadow looks like
<sylvaing> would actually prefer june, early august at the latest.
just remembered I'm getting married around that time (ahem)
<bradk> Congrats!
(office discussions)
<TabAtkins> woo!
<dbaron> sounds like things moving towards Mozilla/Mountain View in
March and Tokyo in June or so...
<fantasai> Adobe, Opera, Google, and Mozilla will check availability
for Tokyo in June
<bradk> Where/when is next tpac?
<fantasai> boston november 2011?
<gsnedders> bradk: November, Lyon
<gsnedders> OR you mean after that?
<dbaron> fantasai is guessing about Boston November 2011
<dbaron> but it seems somewhat likely
<bradk> K, thanx
<sylvaing> if Mozilla hosts in Tokyo in August, shouldn't someone else
host in March ?
(discussion of weather continues)
<jdaggett> sylvaing: talking about tokyo in june
<jdaggett> at (mozilla, adobe, google, or opera)
(holiday family reunion discussions)
<sylvaing> jdaggett, check. thx.
(minuter taking a break)
<fantasai> first week of June, 2nd half, works for me, Bert, and Steve
<fantasai> glazou, too
<sylvaing> sylvaing++
(calendar math discussions continue)
<dbaron> 2nd half == wed-thu-fri
<fantasai> WTF first week of June
<fantasai> 1-3
<fantasai> I think
<jdaggett> jdaggett: yeah, june 1-3 sounds good
<dbaron> dsinger says bad for March 14 or March 21 weeks
<dbaron> Elika has conflict Feb 26
<jdaggett> talking about early march at mozilla in mv
<jdaggett> week of feb 28th/march 7th
<dbaron> Feb28-Mar1-Mar2 is a M-T-W
<bradk> Sorry, is the meeting over?
<gsnedders> bradk: You think they can agree meeting dates that quickly?
<dbaron> Mar 2-3-4 (W-R-F) or Mar 7-8-9 (M-T-W)
<glazou> bradk: yes tech discussions over
<Bert> We're just discussing ftf dates, no more topics for today.
<bradk> OK. I don't think I have anything to block me for 2011 meeting
dates at this point, so I will sign out. Bye.
<dbaron> SXSWi is Mar 11-15
<dbaron> ok, so tentatively Mar 7-8-9 (M-T-W)
glazman: that's it for today
Meeting closed.
Received on Wednesday, 1 September 2010 03:11:37 UTC