<TabAtkins_> fantasai: There are tons of features - it's a very early stage draft - so we don't know that yet.

<TabAtkins_> glazou: I just didn't expect such a massively positive reaction to it as we got.

<TabAtkins_> szilles: So this falls into "careful what you promise, they might ask for it".

<TabAtkins_> glazou: So I'm specifically asking for devs to evaluate implementability as soon as possible on that feature.

<TabAtkins_> fantasai: What's in :matches() is absolutely implementable, since it's just syntactic sugar.

<TabAtkins_> fantasai: So we don't need feedback on that.

<TabAtkins_> fantasai: (At least, not immediately.)

<TabAtkins_> fantasai: It's the subject indicator that needs feedback.

<dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=418039 is the Mozilla bug on :subject

<TabAtkins_> tantek: What about :has()?

<arno> indicator -> selector

<TabAtkins_> tantek: It's in jQuery, it's been adopted and liked.

<TabAtkins_> fantasai: I specifically went away from that because it's harder to ipmlement.

<TabAtkins_> TabAtkins_: Simple useful example: "label:has(:checked) + p"

<TabAtkins_> fantasai: You can use :matches() and the subject indicator to do the same.

(Tab's example doesn't work, does it? The p is not a sibling of the label, but a sibling of the labels's parent.)

<TabAtkins_> fantasai: "label:matches(? > :checked) + p"

<TabAtkins_> fantasai: [explains her example further]

<dbaron> Clearly we should just use the ‽ operator or the ¡ or ¿ operator.

<tcelik> please no more symbols with strange meanings

<dbaron> ok, how about the 美 symbol :-)

<TabAtkins_> dbaron: The spec should say that using the subject indicator twice in a selector makes it invalid.

<TabAtkins_> tantek: I still think :has() is a superior syntax. If you want to put restrictions on its functionality to match the subject indicator, fine, but use the better syntax.

<dbaron> Let's avoid Dr. Streetmentioner's 1001 Tenses for Time Travelers

<TabAtkins_> fantasai: The interesting cases that :has() allows are precisely those that are much harder to implement.

<TabAtkins_> fantasai: Selectors *never* go down multiple branches when matching, right now.

<TabAtkins_> fantasai: Tab's example requires going down one branch and then going down another.

<TabAtkins_> Bert: The XPath syntax may be eaiser here, where it has an explicit ancestor selectors.

<TabAtkins_> dbaron: It's less hard to implement, than that it's hard to track dynamic changes.

<TabAtkins_> dbaron: For example, if you're selecting (in Tab's example), when the input is checked or not, you need to quickly figure out which elements need to be restyled, without redoing the entire page's layout.

<TabAtkins_> RESOLVED: Publish Style Attribute PR as soon as we have the impl reports.

GCPM

<TabAtkins_> howcome: I'd like to talk about what's new.

<TabAtkins_> howcome: Most of this is based on page flaots, but also paged overflow.

<TabAtkins_> howcome: You can tell an element to overflow into pages.

<TabAtkins_> tantek: So it's a manual <marquee>?

<TabAtkins_> howcome: The other thing from GCPM is page floats. These photos [in his slides] are floats spanning multiple columns.

<TabAtkins_> howcome: It works even better on a tablet.

<TabAtkins_> howcome: So basically we can create an e-reader.

<TabAtkins_> howcome: Paged layouts have been used forever in real life. Also in lots of apps, like flipboard.

<TabAtkins_> howcome: [shows an example of paged wikipedia]

<TabAtkins_> howcome: It has a lot of nice properties.

<TabAtkins_> howcome: It avoids cut lines on the top and bottom of the screen when scrolling, frex.

<TabAtkins_> howcome: Some things were *designed* for paged presentations, like children's book.

<TabAtkins_> howcome: There's tons of gutenberg text, for example, that nobody will read because it's not paged.

<TabAtkins_> [shepazu objects]

<TabAtkins_> howcome: We've ipmlemented it in Opera, and have a OM for it.

<TabAtkins_> howcome: [shows example of some presentation showing the current page, etc.]

<TabAtkins_> howcome: It's very simple. The basic setup is with a 'paged' value for overflow, and the nav is done through an at-rule.

<TabAtkins_> plinss: How does it print?

<TabAtkins_> howcome: Quite well. Opera doesn't print well, but if you pipe it to a good printing tool, it works well.

<TabAtkins_> plinss: When you're doing pagination of an element in the page, what happens when you print the whole page? Where's the overflow?

<TabAtkins_> howcome: [shows the code example to set it up]

<TabAtkins_> fantasai: Since the overflow property on <html> is propagated to the viewport, you don't need the height:100% there.

<TabAtkins_> fantasai: Last time, we were thinking of having 'paged' be a value for overflow-style.

<TabAtkins_> howcome: Yes, 'overflow' is a shorthand. The value can go anywhere, it doesn't matter right now.

<TabAtkins_> howcome: You can distinguish between pages being side-by-side, or below each other.

<TabAtkins_> tantek: In Japanese, you get pages right to left.

<TabAtkins_> fantasai: So you also have to check writing-mode, not just direction.

<TabAtkins_> howcome: Right. If I say "paged-x", I take whichever logical direction is horizontal.

<TabAtkins_> shepazu: The scrollbar gives nice discoverability of how much content is left. Is that still there?

<TabAtkins_> shepazu: Could there be a property that adds an indicator of the expected flow left?

<TabAtkins_> shepazu: "If there's another page, put an indicator there"

<TabAtkins_> plinss: There's an example in the spec with "paged-x-controls" for that, I guess.

<TabAtkins_> glazou: How does this interact with @page rules?

<TabAtkins_> howcome: Right now, our impl doesn't pay attention. In the future, if you set the viewport to be overflow:scroll, it'll interact.

<TabAtkins_> howcome: If a line runs over the page (in the direction perpendicular from the main scrolling direction), it just gets cut (you can't see it in any way).

<TabAtkins_> howcome: Same as with multicol.

<fantasai> Tab: These us multicol, so you have columns: 3 or whatever.

<fantasai> Tab: If you're using columns, the overflow columns are to the side.

<fantasai> fantasai: The columns are not overflowing the box. They're overflowing the page, and go to the next page. It just happens that the next page is physically placed to the side rather than below in this case.

<fantasai> howcome: you see this in tablet apps, that do this repeatedly

<fantasai> howcome: This is a very simple sketch.

<fantasai> howcome shows page shift effects

<fantasai> Brad: I think that should be up to the UA, so the UA can provide a consistent interface

<fantasai> glazou: I don't see it as only for tablets. It's a wonderful spec to match the effects of switching slides in a powerpoint

<fantasai> glazou: I think the primary usage of that will be slideshows, much more than tablet browsing

<fantasai> molly: possibly, but I can see designers really loving it

<fantasai> glazou: You can define navigation between 2 pages in same document, or between 2 documents.

<fantasai> glazou: One issue we have with slideshows to dissolve one slide and show the next slide; we don't have the next slide yet when we load the document.

<fantasai> molly: I want to make the case for this and not just slide shows.

<fantasai> molly: Anyone read the NYT? Exactly what people are doing in NYT reader

<fantasai> molly: it's being adopted a lot esp by older users who are not computer-savvy

<fantasai> howcome: Met with NYT last week, who are doing all this in JS. They are saying please save us from the javaScript

<fantasai> howcome: I'm really euphoric about this. I think it's the best thing that's happened in a long time.

<fantasai> sylvaing: Since the Romans!

<fantasai> howcome: It's so simple. No new properties, just new values on existing properties

<fantasai> howcome: And then it's the at-page tihng, which attaches to link elements in HTML

<fantasai> howcome: here we tie thse relationships to the directions with an at-rule

<fantasai> howcome shows example of @navigation using link-rel() notation

<fantasai> howcome: If we want to compete with the apps here, I think we need to provide this form of interaction

<fantasai> plinss: I think it's great on the root element

<fantasai> plinss: When its on the child element, and you turn the page, what happens?

<fantasai> howcome: Here it's on the child element

<fantasai> plinss: Now hit print.

<fantasai> howcome: I see your point.

<fantasai> fantasai: I think you should print the page over again with the next child page until you run out of content in the child

<fantasai> fantasai: Would solve lots of problems with fixed positioning

<fantasai> fantasai: Although it would be weird if you had more than one paged child

<fantasai> Tantek: Shouldn't print starting at what you're looking at, should print the entire document.

<fantasai> Tantek: Wrt slideshows, it's horrible because then you don't get anchors to the slides

<fantasai> tantek: If you do it with anchors tags, HTML5 history, fine. I've built that.

<fantasai> Tantek: But you can't do dynamic paging with anchors

<fantasai> plinss: It's the same problem of scrolling down to a page and wanting to point someone at that point.

<fantasai> Tantek: yes, but the expectation is different: if I'm on a page, I expect to send a link to the page. If I'm in a scrolling document, I expect a link to that page to point at the top

<fantasai> ...

<fantasai> howcome: If I'm at the end of the document, it goes to the next one

<fantasai> Doug: How do you know what's the next document?

<fantasai> howcome: with HTML <link> tags

<fantasai> howcome: you tie them to the navigation like this

<fantasai> Doug: As you go to a new page with a fragment identifier, you update to that fragment identifier. That solves Tantek's problem.

<fantasai> Tantek: Multiple navigation with a child?

<fantasai> jdaggett: If you have 2 elements that are paginated

<fantasai> Tantek: You'd have to scope per fragment the navigation rules if you have a paged child inside a paged document

<fantasai> glazou: Just use a page break there. Define a page break after your sldies

<fantasai> howcome: For slides that's fine. But for a newspaper article you don't want all the newspaper articles in one document.

<fantasai> howcome explains url-doc()

<fantasai> glazou: I think you shoudl resurrect selectors on the right-hand side. This is too specific to HTML. Should be able to do this in any kind of markup

<fantasai> glazou: Should be able to retrieve URLs from link anywhere in the prose.

<fantasai> glazou: Smells like selector on right-hand side of property

<TabAtkins_> We have an existing function that can be used here - element()

<fantasai> glazou: Looks like attr(link[rel=index], href)

<fantasai> Doug: there's nothing HTML-specific about link relationships

<fantasai> glazou: Next step that you are going to take Håkon is showing multiple pages into one single viewport

<fantasai> glazou: To be able to select 5th page directly for example.

<fantasai> glazou: So I suggest you think about this andput it in your proposal

<fantasai> howcome: I'm going ot show you a book I printed in CSS.

<fantasai> howcome: This is a replication of {...} from 1879. Each word on exactly the same page.

<fantasai> Bert: If I swipe right to the next document, expect that going left brings me back. But that depends on the navigation styles in the other document

<fantasai> Steve: I think it's a mistake to put the navigation in the style here. If you want to link together a bunch of document, should have some kind of manifest.

<fantasai> plinss: this is outside the scope of CSS, but yes there's a use case for some kind of manifest that expresses these relationships

<fantasai> fantasai: The links among documents can be expressed in HTML. The bit that's out-of-scope is mapping those to navigation gestures

<fantasai> ...

<fantasai> plinss: It should be next and previous

<fantasai> howcome: That's already in the HTML, don't need the CSS.

<fantasai> Tantek: Request to add a photo of the folks that were here 7 years ago

<fantasai> Steve: I think there's a difference between what happens in a document, which you specify wiht paged-x and paged-y, and what happens across documents, where I don't think it's the role of CSS to say. But getting to the end of a document is an event, and you could say what happens when you get to that event.

<fantasai> glazou: I have a lot of comments on your document.

<fantasai> howcome: Email probably works better if we want others to participate as well.

<fantasai> howcome: So this is most of what's new in the GCPM. Maybe continue tomorrow?

<fantasai> Meeting closed.

<fantasai> book was Digte by Henrik Ibsen

<arronei> fantasai: you mentioned the template that I should use for the IR. Can you point me to it?

<arronei> fantasai: ping

<fantasai> arronei: pong

<fantasai> arronei: http://www.w3.org/Style/CSS/Test/CSS3/Namespace/20090210/reports/implement-report.html

<fantasai> arronei: sorry, was studying gradient syntax

<myakura> day one (zero?) minutes: http://www.w3.org/2011/10/30-css-irc

<Ms2ger> crosoft), John Jansen (Microsoft), H�kon Lie (Opera), Peter Linss (HP), Chris Lilley (W3C), Vincent Hardy (Adobe), Rossen Atanassov (Microsoft)

<inserted> Scribe: Bert

<Ms2ger> That's better

<glazou> test

Round of introductions

<fantasai> http://www.w3.org/Style/CSS/Tracker/products/8

Values and units

<fantasai> http://www.w3.org/Style/CSS/Tracker/issues/193

fantasai: Issue 193 is about removing <fraction> and <grid>
... Not sure they are actually used anywhere.
... Apart from unstable modules.
... If necessary we can add them back in Level 4

Florian: Sounds reasonable. No hidden issues?

Markus: If another spec needs it?

fantasai: Some modules already define their own units.

RESOLUTION: remove <fraction> and <grid> (ISSUE-193)

fantasai: ISSUE-195 is next
... In CJK
... fonts typically have 1em advance.
... We have a ch unit.
... Compressed CJK fonts do not advance 1em.
... Dow we want a new unit for CJK fonts advance?

Florian: Is font is proportional?

fantasai: No, for compressed, but still monospaced fonts.

JohnD: Don't think we should add it.

<dsinger> …thinks it might be good to have a FAQ explaining the difference between the working group, the interest group, and the community group...

JohnD: It is not going to help you.

fantasai: Our feedback was that a line consisting only of ideographic characters should be set solid,

JohnD: how do you get the value?

fantasai: Same way as ch unit.

JohnD: Did you ceck that fonts actually give that info?

Koji: [didn't hear]
... Definition in Opentype.
... "if this table then use that"

JohnD: I'm sceptical.
... Would like to see a post on www-style, with use-case

[A monk or ghost or... enters the room]

<Ms2ger> Hi!

ACTION koji post use-case on www-style. Then we'l look at actual fonts.

<trackbot> Created ACTION-386 - Post use-case on www-style. Then we'l look at actual fonts. [on Koji Ishii - due 2011-11-07].

Positioned layout module

<arronei> http://dev.w3.org/csswg/css3-positioning/

arronei: [shows module on screen]
... Updated with feedback fromlast ftf

<arronei> http://wiki.csswg.org/spec/css3-position

arronei: See also the issues list
... ... Still need to discuss some things with Tab.
... Today topic is page positinion and centering.
... Page position is absolute, but looks a bit like fixed.
... Mainly meant for Regions.
... A ddeply nested regions can still be positioned relative to page.
... If not in a region, position is relative to intial CB.
... Possible problems with overlap in that case.

Howcome: Hard to understand without examples.

arronei: Regions create new initial containing blocks.

howcome: Can you put something in a position on page 3, e.g.?
... 'position: page' with offset.

fantasai: Overlap if you are not on the page you expected to be on.

arronei: Really focused on regions.

fantasai: Don't ike that fallback behavior.

howcome: Yes, that is a problem.
... Page floats don't have that problem.
... Next float autom. goes beneath previous one.

fantasai: page pos. seems to break too easily, and very badly.

[dicsussion about cases]

fantasai: At leats with foats everythign remains readable, visiible.

arronei: I hear some concerns. What is general feel?

Peter: Some cases you may not care so much, e.g., create a watermark.

arronei: Shall we pull it out then, for now?

Steve: For named pages, can you use the name?

fantasai: abs. pos is not the greatest thing with pagination.
... This sulution is broken enough to need redesign.

arronei: Do you already have a better solution?

fantasai: Not really.

arronei: We need something eventually.

Steve: We'll need some way to make a seq. of pages with each their own structure.
... As we said already with howcomes' demo yesterday.

Tab: Something like float's ability to reposition itself.

fantasai: important is that it doesn't break horribly if things aren;t exactly as expected.

<dbaron> (various): Changes to the page size, margins, or font size can cause things that were positioned on different pages to be positioned on the same page, so that they overlap.

arronei: If you adjust the margins on a page, you may easily get two elements on the same page where you didn't have them before.

<fantasai> fantasai: This will break if you either paginate differently or display in scrolled media

Alex: Anything available that would work?

howcome: page floats!

alex: Still need to get something in top right if you want it in top right.

[forgot name]: confusion between clearing and positioning.

scribe: Position page is not necessarily the feature at risk. It lacks clearing, yes, but if we solve that, we don't have the fallback pb anymore.
... Do you propose to pull the feature to solve positionin or solve clearing?

Florian: both.

Alex: Exclusion, positioning and floats all needed, 3rd part not done yet.

howcome: page floats works, in spec and tested in implementation.

arronei: find middle ground.

Tab: floats don't overlap, that is the big difference.

fantasai: My issue is that something that is desgned such that the fallback nearly always fails, is not good.
... We can leave it in ED, but shoul dnot be like this in WD.

Alex: Want to be able to
... EGneneral solution for floats is complex.
... We eant that, but want excat algos.
... postiioning to page is very important.
... Needed for pages with exclusions.
... Some of their logic will have to be inscripts.
... Very hard to do without positioning to page.
... [something]

Tab: only for scripts, you say?

Alex: Probably.

fantasai: So that indicates to me the model is broken and you need a better one.

<fantasai> Alex^: This will only work well with multiple positioned items if you have script

Tab: We should not right something that is broken just because we don't have time for the better one yet.

arronei: We should think about clearing, not decide it right now, but think.
... Can put it in Editor's Draft.

Steve: Put in the ED what tje issue is, and what arguments are,

fantasai: and look for other solution for same use cases.

arronei: I can put that in.

Brad: What does page float not solve that this does?

Steve: yes.

Alex: something that is positioned and does not collide with orther things is a page float.

howcome: We should find use cases and solve the pb.

Brad: So this is complementary to page floats?

Alex: In the future we need page floats that can be positioned abs. on a page.
... Don't worry that we will have that some time in the future.
... We want more, but what we have is good enough for now.

Howcome: We want the use cases to be solved, but we also need the fallback. Cannot rely on scripts to solve the fallback.

fantasai: Good summary!

Alex: We have no media selector to distinguish scroll from paged.
... Let's make floats work.

arronei: Yes, but we need to move this spec. There aren't many issues left.

<fantasai> Tab^: It's not about paged vs scrolled. Even within paged media, this breaks if you change the pagination

<scribe> ACTION: arronei to details issues further and come up with use cases and solve them better (for values and units) and pull page positionin out of WD. [recorded in http://www.w3.org/2011/10/31-css-minutes.html#action01]

<trackbot> Sorry, couldn't find user - arronei

<scribe> ACTION: arron to details issues further and come up with use cases and solve them better (for values and units) and pull page positionin out of WD. [recorded in http://www.w3.org/2011/10/31-css-minutes.html#action02]

<trackbot> Created ACTION-387 - : details issues further and come up with use cases and solve them better (for values and units) and pull page positionin out of WD. [on Arron Eicholz - due 2011-11-07].

arronei: Need to handle the cases were there is overlap.
... About center positioning:
... Very old request.
... It is now similar to block-level non-replaced centering with auto margins.
... Margin: auto wouldn't work here.
... There is a calculation in the spec.
... Set 'position: center'

Alex: bottom positioning is a problem.

fantasai: This allows us to position out of flow obkects, but stil not in-flow objects.
... And that is more important.

Daniel: Agree.

Tab: Can use flex box, or grid.

dbaron: Proposal is reasonable for positioning.
... Could add something about auto margins, not defined currently.

Tab: horizontal only, or vertical, too.

dbaron: Symmetric.

fantasai: No, it is not symmetric.

arronei: We'll keep this part in the draft.

dbaron: you can center vertically with auto margins, in level 2, as long as height is fixed.

[discussion about case with height: auto]

arronei: Should work for auto height, so I'll correct that.

dbaron: For centering in each dimension you need to set four properties and set height.

arronei: Some other issues in the spec:
... No ruby values.
... Not sure what a positioned ruby works.

dbaron: Do the spec need to redefine CSS 2.1 section?
... Can't you just say it amends CSS 2.1 for these cases?

Tab: Do we want to write delta specs?

Chris: We decided to refer to CSS 2.1 from level 3 modules.

Tab: Yes, but not the same thing.

Chris: We decided that level 3 can refer to CSS 2.1 and to other modules.

Steve: A module is self-consistent. It refers to other specs, of course.

fantasai: Modules replace CSS 2.1, also to make tetx more readable.
... This spec should not define display types not un CSS 2.1.
... Flex Box defines its own display types and their interaction with this spec.

arronei: So I only need to refer to 2.1 dusplay types here. OK.

dbaron: You need to redienf the term "absolutely positioned" to include center aned fixed.

<dbaron> http://www.w3.org/TR/CSS21/visuren.html#absolutely-positioned

<dbaron> http://www.w3.org/TR/CSS21/visuren.html#position-props (positioned)

arronei: Next is inset-rect.

dbaron: Yes, we resolved to add that some ten years ago :-)

arronei: So I think we're OK with this part.
... Last issue is stacking context and opacity and transforms.
... Couldn't find any coclusions about that.

dbaron: Both opacity and transform on elts without z-index, than act as if z-index is 0.
... If it is positioned and has a z-index, than use that.
... Otherwise do as if z-index is 0.

arronei: Implementations seem to do that, indeed.
... How about transforms?

dbaron: Believe they ar ethe same.

sylvain.: I will add that to this section.
... Can we then move this to WD?

daniel: I think we should. Objections?

[no objections]

<dbaron> see http://lists.w3.org/Archives/Public/www-style/1999Jul/0014.html for inset-rect() :-)

RESOLUTION: publish positionong as WD.

daniel: One remaark: you cannot actually search for "issue" in the draft.
... Can that be fixed?

fantasai: I think it is a bug in browsers that they don't find generated text.

daniel: But we need a way to find issues now.

Animations

[discussion about agenda, break, joint meetings...]

Daniel: yesterday already some issues.

Dean: Most editorial issues were addressed already. So we can today talk about difficult issues.

sylvaing: What happens when an anim is cancelled: is there an event?

dean: You meand, ended before it coempleted
... What would you do at that point?
... Just a notification?
... I'd be OK with that.

sylvaing: Need to put in one place all the things that can happen on cancellation.

Dean: Give me an action to add an event?
... Display: none is tricky.

sylvaing: People expect that properties continue to change, even if you don't see anything.
... But you can achive that with a delay.

Dean: Computed style of a property exists even when display is none, doesn't it?

dbaron: starting an animation is result of computing a value.
... We don't define *when* you comnpute style.
... Just assume it happens at proper time.
... Authors depend on display: none not have performance effect.
... But changing this will have such a performance effect.

Shane: not so much impact.
... Only look at a selectors that apeopley.

sylvaing: Animation delay solves it.

dbaron: Not so sure about shane's performance assessment. There's also memory, and inheritance.

shane: It doesn't fundamentally change behavior of 'display: none'

dbaron: It doesn't change for authors who don't have animations.
... But it doesn change where thare are animations.

shane: Yes, in some cases.

[discussion about impl. architecture and impact, cscribe didn't udnerstand]

Chris: The author expect that hidden stuff is still up to date.

sylvaing: Use delay.

Tab: Cannot know delay in advance.

Dean: Calculate time line in advance for part of the treee
... In some future version of the spec we can define that animations can be aligned.
... Problem that we cannot do that now.
... But we can still say things in current spec so that implementations don't have to compute for elements with display: none.
... No events.
... You could use script and set delays as well.
... What happens if you animate 'display: none' in a key frame?

Tab: As soon as we can animate keywords, you mean.

Dean: Yes, that is not yet in spec, but will add it.
... I propsoe display: none means element is not animated.

Luke: What does it mean?

Dean: Elements with display: none and anumation property, we don't even look at animation.

Luke: So as author I first need to set to block, than add animation, so GetComputedStyle(), then set display again.

Dean: Not sure I understand.
... Just set display: inline or whatever and animate.
... The rules for starting an animation should include that animation starts as soon as display changes from 'none'.

Shane: Could get interesting.
... Change in display may trigger an animation.

Dean: Is that any worse than applying animation styles? Performance hit?

arronei: Problem if middle key frame has 'display: none'

brad: Say I want to move from left to right in 10 sec, and after 5 secs I set display.

dbaron: So question is if display becomes none in middle of animation and then becomes block again, does animation continue? Gecko does that.

Brad: So I can stop animation that way and get my use case?

[Scribe didn't understand]

Florian: Spec doesn't really say it has to be that way.

Tab: Say 'display: none' is set during animation.

dbaron: We recompute style while the animation is running.

Tab: It won't restart until the display: none goes away?
... Mental model is not obvious.

Florian: Simpelr to say display: none doesn't animate?

sylvaing: We still need to define

Shane: Should we look at implications for perf. of running in display: none?

Markus: Also look at battery life.

Dbaron: Animation can stop while display: none is in effect, you still need to detect that.

Luke: No need to do that in real time.

dbaron: Yes, need to do that at each tick.

Luke: What if element itself is removed?

dbaron: We remove the animation as well.

Tab: It doesn't have any CSS anymore at hat point, that is a distinct case.

dbaron: We explicitly stop animations when an element moves in the DOM.
... We have the code to preserve animations during display: none' preceisley to deal with the DOM issues.
... Harder to do if an ancestor has 'display:none' instead of the elet itself.

Tab: Model is really confusing, except if you understand browser kernels...
... Simplest is that animations keep running, even if not displayed.

[scribe missed some]

Dean: Take a spinner, and you set 'display: none' to hide it and expect it to start from zero when it reappears.

Tab: [explains an solution]
... Instead of putting anim. on spinner. set it on spinner.shown.
... No restarting involved.
... Just add/remove the class when needed.

[some discussion not minuted during netwok outage]

Molly: When displauy is none, animation should not apply.
... That is easy to explain.

sylvaing: But what if display is set to none in middle of key frame?

molly: Keep consistent.

Florian: Set none at 50% just kills the animation, that is consisytent.

<ChrisL2> Forclarity,I prefer to modify what Molly suggested - when display is none, CSS animation must not apply

<ChrisL2> (because smil-based animation does apply when display=none)

Steve: display triggers a relayout, can use visibility hidden instead.
... So letting display: none turn off anim seems reasonable.

Markus: Steve's solution is good.

dbaron: So I hear consensus that display: none breaks animations, stops them.

RESOLUTION: Two new co-editors Sylvain and David

<dbaron> RESOLVED: CSS animations do not start or continue running on elements that are display:none or inside display:none elements

[break]

[Joint meeting with WebApps, see their minutes]

<glazou> see #webapps

[See #webapps]

<Ms2ger> ACTION Tab to write proposed example text for CORS

<trackbot> Created ACTION-388 - Write proposed example text for CORS [on Tab Atkins Jr. - due 2011-11-07].

<glazou> Ms2ger: you're in the webapps room ?

<Ms2ger> Yes

<glazou> ooooh

<Ms2ger> The IRC room, that is

<glazou> ah

<glazou> not physically at tpac

<Ms2ger> No, physically I'm sitting in my bedroom :)

<glazou> k

<glazou> Ms2ger: please don't file action items for CSS WG

<Ms2ger> OK

<glazou> thanks

s/Sylvain and David/Sylvain and David for Animations module/

s/netwok/network/

s/preceisley/precisely/

s/at hat point/at that point/

s/perf./performance/

s/Simpelr/Simpler/

<dbaron> [11am-noon was a joint meeting, scribed in #webapps]

<fantasai> RRSAgent: make logs public

<fantasai> ScribeNick: fantasai

Animations (cont)

sylvaing: Issue is what if a property is not specified in all keyframes.
... Also what if one keyframe has an invalid value

animations [cont'd]

dbaron: What happens in gecko when a property is not valid in all keyframes: every animations animates all properties that are in any keyframe of the animation, over the entire duration of the animation
... The animation interpolates each property across the keyframes from the keyframes in which the property was present.

dbaron gives an example

smfr: Imagine exploding keyframes into keyframes per property. For keyframes in which the property isn't specified, you ignore them.

dbaron: The fun case there, and one I'm not sure we agree on, is what happens if some of the values are value syou cannot interpolate between

<TabAtkins_> sylvaing: So if I had an animation with keyframes at 0%, 50% and 100%, and 'width' appeared only in 0% and 100%, it just animates between those two values and ignores 50% (for 'width')

dbaron: In Gecko, if there are such values, I drop the property from animatio completely
... So if you animate from width: 100% to width: 50% to width: auto, I say you can't animate between 50% and auto, so I'm not going to animate 'width' at all

Luke: If you have, say, an abspos div and it's specified left in the initial state and right in the final state, you can't actually do an animation for that thing.

smfr: same problem as not being able to animate t/from auto

dbaron: Another issue here from testcase on www-style last week (from Lea?)
... In some cases, the computed value of one prop depends on computed value of another property
... If your animation is multiple properties, what basis values are you using?
... So in Gecko, I didn't really think about this when implementing, so what I implemented is that it ignores other properties in the animation
... That's probably wrong
... If we want this to work right, for some definition of right, things can get pretty complicated quickly
... So I'm not sure what to do there.

example was animating stuff in ems and font-size (?)

Luke: Has anyone considered doing this in computed space instead of precomputed?

Tab, dbaron: Happens over computed values

Luke: Instead of being mes and whatever, then you'd want these things to be final pixel values
... Instead of ...

dbaron: You want to animate used values instead of computed values. That's hard because it depends on layout. Would rather not go there.
... I'd be more interested in solving those problems by making things like calc(50% + 2px + auto) work
... or calc(auto * 0.5)
... Then it's much easier to solve these problems

smfr: theoretically you could lay out at the final state to find what 'auto' means

dbaron: The problem there is that might depend on other things that animate

smfr: So does Gecko explicitly not do animations that involve 'auto'?
... In WebKit we treat 'auto' as 0
... That makes things like left -> right work

Luke: So if you have these calc() expressions, you can defer layout

dbaron: Yes, you can do the animation on computed values and then you do the layout with the interpreted calc() expression
... background-position has a problem, too -- it needs calc

Shane: It's pretty much impossible to animate gradients without deferring layout
... For gradients, you can't generate and interpolate a computed state. You need to do layout

dbaron: I think we have a lot of agreement on this. We need to write it up.
... a) How the loop over properties works: properties, the keyframes
... b) be clear that interpolation happens on computed values (think we say that already)
... c) Issue on what to do with non-interpolable pairs in the animation

fantasai: dropping it entirely seems like a better idea. More straightforward, and if we later figure out how to interpolate it and people add it, it'll either work or not work (in olde rbrowsers): you don't get this halfway jumpy thing

smfr: If the property is missing from a 100% keyframe and the animation is looping, you could look for the next value in the loop rather than going back to the base value

fantasai: so if you only have a property specified in one keyframe

smfr: It would go from base value to that value, stay at that value, and then come back down to the base value once you stop animating

sylvaing: next issue is on transition property
... Idea was that you could set a duration for all properties
... and then override that separately

sy And we talked about the none case. We said that if you have 'none' in the list of properties, that kills everything before it

dbaron: Right now none and all can't be part of a list

sylvaing: We agreed to fix that

dbaron: Missed that thread
... Seems like it makes more sense for all than none. Maybe fix it for all and not for none?

Dean: So you can't put none in a list, but all you can

fantasai: so, can you put all anywhere in the list?

sylvaing: It will override anything before it

TabAtkins: So 'all' just happens to be a really big shorthand

fantasai: Reminds me of a request for blocking inheritance. Could do "all: initial" for that

plinss: Anything else on animations?

<dbaron> RESOLVED: 'all' is allowed within lists in 'transition-property' (but 'none' is not). Which item wins works like for shorthands, so it's silly to use 'all' other than at the start of the list, but it's not forbidden.

dean: We had an issue on the animation cancel event -- an event that fires when an animation gets cancelled
... The event fires on the element. But what if the element is removed?
... Do you fire on its parent? Or not fire the event?

dbaron: I'm inclined it should fire on the element or it shouldn't fire
... I'm not sure firing an event on something not in the document is something to do

Tab: Not sure it's a problem. Your target phase is weird. You have events firing at DOM non-elements all the time

dbaron: I'd prefer to ask a DOM Events expert; I'm not one

dean: If we do decide to fire on an element that's no longe rin the DOM, then it obviously can't bubble up to its parent.
... Typically people want to listen for events on an ancestor
... I'm tempted to say it doesn't fire

Tab: I'm not certain if I want to object yet.

<Bert> s/longe rin/longer in/

Dimitri says something about not getting an event on an event listener

scribe:

AlexRussell: In webkit [...]

AlexRussell says something about bubbling being useful...

Tab: Ms2ger says that firing a DOM event on a disconnected element should be fine

RESOLUTION: Fire the event on the disconnected element

plinss: Does anyone want to check with other DOM Event experts on that?

dbaron: I'll double-check with smaug as well

plinss: Anything else?

<dbaron> ACTION dbaron to write up description of how animations of properties only in some keyframes work

<trackbot> Created ACTION-389 - Write up description of how animations of properties only in some keyframes work [on David Baron - due 2011-11-07].

sylvaing: One interesting piece of feeback from ppl internally using them to dev applications

<dbaron> ACTION dbaron to check with smaug about firing DOM events on disconnected elements

<trackbot> Created ACTION-390 - Check with smaug about firing DOM events on disconnected elements [on David Baron - due 2011-11-07].

sylvaing: They're trying to animate inset box-shadows to outset box-shadows, and it doesn't work

dean: We could do that..

<Bert> s/feeback/feedback/

smfr: I almost did that at one point, but gave up because it seemed a little tricky
... What do you do with spread, if it's nonzero?

dean: I still can't work out how you'd do it.

fantasai: You'd have to bring everything down to zero, then bring it all back up on the other side

dbaron: Could you pretend that instead inset, you use negative numbers?

fantasai: You could define this, but it wouldn't be simple: have to bring the offsets and spread and blur radius down to zero and bring them back up. Do you do that simultaneously, one after the other?

dbaron: If someone comes up with a way to represent all these intermediate states

plinss: You want to make it look like raised above, then you're sinking it down

dbaron: You have to model it with a light source

TabAtkins: The shadows are not necessarily representable by a single light source

dbaron: Assume the light source is a point at inifite distance, and then only modify the distance fo the box to the canvas

dean: With a special model of physics, we can come up with a model for hte animation of inset to outset box-shadows. :)

smfr: Any more serious issues?

<dbaron> assume the light source is 45 degrees from vertical

<Ms2ger> s/inifite/infinite/

Seems we will consider animating inset to outset box-shadows iff someone comes up with a proposal of exactly how that's supposed to work.

plinss: They all have to hit zero at the same time or its going to look stupid

dbaron: I could try writing it up, but not sure it's a high priority

<ChrisL> so the question is hopw to simultaneously animate three properties throuh zero and out the other side without a discontinuity?

fantasai: I think you have more important things on your to-do list :)

szilles: +1 to taht

s/taht/that/

<dbaron> I think it's relatively straightforward to break down each shadow as something created by an infinite light source and a box elevation.

RESOLUTION: Will consider animating inset to outset box-shadows iff someone posts a proposal of exactly how that's supposed to work.

<dbaron> assume the infinite light source is at 45 degrees for both endpoints

<Bert> text-combine-horizontal property

Regexp matching and values of text-combine

Florian: We rejected regexp matching in selectors, but you have to do similar for text-combine

Florian is asking for the ability to make pseudo-elements out of something that matches a regexp

jdaggett: yes, it's a contextual role, but it's far more finely scoped

fantasai: When you're dealing with text-combine, you're doing it as you're evaluating the text. It's not part of selector matching.

Florian: Just a question, not an issue.

<Bert> fantasai: from the spec: " If the content contains any element boundaries this is treated as ‘text-combine-horizontal: none’ on the element and any descendants."

<Bert> ... It's atheoretical box, as soon as you notice a boundary you abort constructing it.

<Bert> Tab: OK, clear what is supposed to happen, still have editorial reservations.

<br type=lunch>

<Mike5> tantek, we talking about Web Intents in WebApps WG room

<Bert> </br>

<anne> you realize that ends up in the DOM as <br> right?

yeah, doesn't matter

it's one break

:p

<anne> you forgot the namespace!

whatevver

<scribe> ScribeNick: fantasai

WebApps/CSSWG Joint Meeting Resolution

jdaggett: We resolved to make the font loading @font-face same-origin by default
... Two actions on me

<scribe> ACTION: jdaggett to Reword how same-origin is described to talk only about HTTP [recorded in http://www.w3.org/2011/10/31-css-minutes.html#action03]

<trackbot> Created ACTION-391 - Reword how same-origin is described to talk only about HTTP [on John Daggett - due 2011-11-07].

sylvaing: Wouldn't this be an issue for implementations?

<sylvaing> my question was whether implementations used CORS or From-Origin; it seems we made a decision on using CORS

fantasai: So if I linked a font on a different server via ftp, that works around the same-origin restriction?

<scribe> ACTION: jdaggett to Talk with Anne about how to reference the same-origin things "correctly" [recorded in http://www.w3.org/2011/10/31-css-minutes.html#action04]

<trackbot> Created ACTION-392 - Talk with Anne about how to reference the same-origin things "correctly" [on John Daggett - due 2011-11-07].

Vladimir: ...

jdaggett: This resolution will eliminate the need for an at-risk rule.

sylvaing: Will there ever be a connection between this and From-Origin

Florian: It's CORS

jdaggett: Once the action items are complete, there will be another point at which we can rehash if need be

<hober> I didn't think we made a decision to use CORS specifically, only to have a same-origin restriction by default in @font-face

jdaggett: So do we have a resolution?

RESOLUTION: @font-face will be same-origin by default with the use of CORS to relax.

for HTTP

Flexbox

TabAtkins: I have a couple outstanding issues I need to edit, but we don't need to worry about -- just reslve corner cases with obvious answers
... Other issue: ATM in the spec flex-order takes a <number>, whereas z-index takes an <integer>
... So we can either make flex-order <integer> or z-index <integer> to make consistent
... Prefer <number> because it makes it easier to insert things in between later

<dbaron> s/or z-index <integer>/or z-index <number>/

ChrisL: what's the impact on z-index of changing it?

TabAtkins: z-index currently takes <integer>, so this would be expanding it.

smfr: I'm a little uncomfortable with changing z-index
... I see a lot of devs setting z-index to maxint -1

TabAtkins: Would the crazy things ppl do be affected by this change?
... I don't think so

Arron: We don't know.

Molly: I'm afraid.
... Designers don't understand CSS. They just hack around.
... What is going to happen if something changes there?

smfr: Whether it breaks depends on the implementation. Opera had a 16-bit implementation at one point

TabAtkins: floats are above our minimums

smfr: You can't represent maxint accurately as a float

TabAtkins: We were talking about required minimum ranges for <integer>
... will almost certainly be below maxint

Florian: Possible ppl are writing floats into their z-index, and their pages currently work only because it gets thrown out

TabAtkins: If we believe that's actually a problem, that there is significant usage in the wild of invalid z-index values, then we have a problem

Markus: what do we lose by not having <number>?

TabAtkins: It's mildly more convenient to use <number>.

Steve: Is the benefit of analyzing this worth the benefit?

fantasai: you can use the BASIC approach and space your numbers by 100

TabAtkins: Make flex-order be <intger> and later evaluate whether to change flex-order and z-index to <number>

RESOLUTION: flex-order as <integer>

fantasai: On another note, why do we have flex-order and z-index?

TabAtkins: I don't care very much, slightly prefer flex-order

<Bert> ('nav-index' is also called "index," not "order.")

Bert mentions tabindex in CSS

'nav-index'

<mollydotcom> re: z-index: request clarification to early scribed comment: "Many designers don't understand CSS, they use properties that we define and understand, but they create hacks to work around implementations or to address a feature they don't know how else to do"

discussion

<tantek> hearing 'nav-index', /me puts down the TPAC planning wiki page and hurries back to CSS WG

Steve: I think 'index' is slightly better because you have to think about what it means, and if you read it you have to look it up
... I think order implies something it isn't

Molly: Many people already understand z-index anyway, and in their vocabulary, so it's consistent anyway

holding off until alex is around

TabAtkins: Last thing is to request WD publication. Last draft is from 2009

dbaron: One reason I hesitate to rename flex-order to flex-index is because boxflexgroupthing might be flex-index

TabAtkins: Oh, you mean like flex-group

dbaron: I guess flex-group is fine

RESOLUTION: Publish css3-flexbox as WD pending flex-index/flex-order issue resolution

alex: flex-order changes processing order, not just visual order so I think it should be flex-order
... did you go over min-width?
... 8, 10, 12
... abspos children

<TabAtkins_> http://wiki.csswg.org/spec/css3-flexbox#issue-10

alex: We had an issue about issue of abspos elements creating an empty, which is discoverable when justifying
... There is no reasonable way to place that hypothetical static position
... Place where it would have been is inline content, and that gets wrapped in an anonymous ocntainer, and that box is empty.
... But justifying with flex-pack shows this placeholder
... Positioning a flex-item without a placeholder is tricky

fantasai: Why not define the static position as coinciding with the flexbox

?

alex: The only thing we don't like is the behavior with flex-pack: justify, and I don't mind it being bad for this case since it makes everything else work better

TabAtkins: So we're embracing the placeholder concept.

Ojan: I don't like that
... Weren't you proposing to point its static position as being in the middle of the flex-pack space

dbaron: that's a lot of code to special-case an edge case

RESOLUTION: abspos elements leave behind placeholders

and all that implies

http://wiki.csswg.org/spec/css3-flexbox#issue-8

Straw poll: flex-index vs flex-order

jj: order

alex: order

howcome: absain

koji: absain

markus: order

tantek: abstain

steve: index

alan: order

florian: abstain

bert: no opinion

?: index

brad: abstain

smfr: order

dean: abstain

<shan> soonbo_han: index

shane: order

<hober> hober: order

luke: abstain

kim, molly, rossen: order

dbaron: order

jdaggett: abstain

sylvaing: order

arronei: order

tab: order

fantasai: index

glazou: I don't care

ChrisL: order

RESOLUTION: flex-order

http://wiki.csswg.org/spec/css3-flexbox#issue-12

TabAtkins: This is to consider z-order axis
... as a flex order
... I believe we shouldn't do anything about this right now
... If we want to address stacked layout, which I think we should, we should consider it as another display or part of grid or something else. Don't have all the primitives we really want
... One thing you might want to do, frex, if you have items of different size, you might want to size to the size of the current item, or size to the size of the largestitem so you don't resize as you swap them
... That's a control that you don't have otherwise

dbaron: What's the use case for size based on the one on top?
... Gecko implements this, and we've never gotten a request for size based on the one on top

Rossen: size otp sounds like a way of deferring layout of the other things, is that your use case?

TabAtkins: Partially
... Have a use case for sizing according to top
... I've seen tab layouts where your headings or whatever are on the side, and the contents of your page are the stack
... You want thema ll to fill the widths. But if you have a tall item and some short items, you don't want the short items to have a long scroll bar

dbaron: Fair enough, but that doesn't seem like flexbox.

Markus: If we add this we'll have another way to do stacking in addition to z-index and grid

TabAtkins: There's still further things that distinguish this from plain flexbox that make it not a good idea to combine
... Flexbox's alignment primitives are flex-align and flex-pack, which are perpemndicular/ parallel to the flex axis
... If you have stack, then you have two orthogonal axes, and it's not clear which is align and which is pack
... If we were going to tack it onto one of our layout models, grid might be better. not sure if it's the best idea, but semes better than this

Alex ...

Alex: If you take a grid and give it several items, it will give you a stack.

<Bert> (Template Layout once had 'display: card | card-container | card-tab'. Came from a request from Device Independent WG.)

TabAtkins: One final thing that makes me hesitant, I'm not sure if we ant to address in CSS, but if you have tab layout then you prolly want to show the tabs themselves.
... Auto-generated, linked up manually, some old proposals, but don't know how
... in JavaScript it's easy, but may wnat to address it in CSS

Alex: HTML5 control using script and grid and add to HTML5 as necessary

TabAtkins: One problem with script is, the tabs should be accessible.
... Most developers will not and do not in practice hit all of the accessibility goals we want there.

Alex: it needs to be an HTML5 control

fantasai: Couldn't you use fragment IDs?

TabAtkins: If we address this automatically somehow via CSS, I doubt we want to tie this into z-index.

<Bert> (http://www.w3.org/Style/Examples/007/target is example using fragment IDs (and :target, thanks to Daniel))

TabAtkins: problem with using z-index is that you want to just deal with the flex items, not everything else on the page

RESOLUTION: Not addressing stack axis in Flexbox

http://wiki.csswg.org/spec/css3-flexbox#issue-14

alex: Do 'before'/ 'after' apply to direction based on writing mode or based on flex order?

TabAtkins: Currently flex-align: start aligns to the beginning of the flex order

alex: flex-align: after goes after the first line (towards the second)

RESOLUTION: logical keywords are flex-relative, not writing-mode-relative, when used in flexbox

http://wiki.csswg.org/spec/css3-flexbox#issue-17

TabAtkins: Let's say it says width: flex(1)
... And you give it a min-width of 50px.
... Should this start the flex calculations from 50px?
... Or should it start from zero and then check/correct if necessary?
... This is important if I want to give each item flex of 1, but set a minimum for readability
... If you make it so that everything starts from the minimum width, this breaks
... Everyone will start at their min-width, then they'll flex, and then they'll be different size
... However, that method is easier
... However I think it is a bad enough behavior that it should be changed
... I'm specifying exactly when min/max are taken into account
... Think we should make sure min/max are handled after flexing.

fantasai: I think I agree

dbaron: ...

TabAtkins: The passes are limited and cheap. It's multi-pass layout, but not full layout. Will converge super-fast.

Alex: Don't think it's possible to avoid multiple returns, but very hard to come up with situation that requires more than one return.

dbaron: Assuming we know how to resolve intrinsic sizes in block dimension

but that's another problem entirely

<dbaron> but one I think we should try to solve in this spec

Alex: Let's say you have flex of 1000px, and your max-content is 2000px and min-content is 500px
... min-width is specified to 100 or 0, doesn't matter
... which of min-width will go to the min, is it going to be min-content or min-width?
... I think what's supposed to happen, if width is 'auto' then we should look at min-content width
... If width is specified, then we should not look at min-content width.

fantasai: I think it makes sense? I think it's consistent with what Tab proposed.

TabAtkins: We're working on an implementation, and you're working on an implementation, so we should be able to figure out what's sane

alex: Question is in what cass do we consult min-content, if ever

s/cass/cases/

alex: Default value of min-width is 0
... so it's always specified

do we need an 'auto' value for min-width?

alex: ...
... Could say minimum is max(min-width, min-content)
... Problem with that is you can never have a box that is smaller than min-content

TabAtkins: Could we say by default things can shrink to zero, and if you want min-content as a minimum, you say min-width: min-content

Ojan: Seems non-flexbox specific

alex: Different because flexibility depends on the width

Ojan: To be consisten with
... if you put min-width: 100px and width: 300px then you'll get 300px

dbaron: Those don't conflict. If you swap them you get 300px

Rossen: The problem is that if you want to achieve parity with ehavior of table cells floaters abspos or anything else that does shrink-to-fit,
... min-content is always respected in these types of layout
... flex in this case doesn't respect the minimum content
... If you have some characters, and default value of min-content is 0, flex will currently shrink all the way down to zero
... might or might not be what you want

fantasai: How about changing the initial value of 'min-width' to 'auto'

?

Rossen: When would you not want min-content?

alex: I have a huge long unbreakable line, don't want to follow that

steve: Wouldn't you want the same thing in a table?

TabAtkins: It's easy to do what we want for flexbox. Still means tables are confusing, but everybody else works the same way.
... If you want min-width of 0, set it to zero. If you want min-width of min-content, say so.

RESOLUTION: Effective min-width on flexes is a limitation after the initial flex resolution, not while figuring out preferred width of element.

dbaron: The way things need to work for blocks and tables is that min-width doesn't affect the pref width of the element, but affects the pref width of the parent

RESOLUTION: minimum width is just min-width: min-content is not an implied minimum

TabAtkins: There was a question when flex-align: stretch combines with 'max-width' smaller than the size of the flexbox so that it can't stretch beyond

s/beyond/fully/

TabAtkins: Proposal is to respect the sizing constraint and then start-align

RESOLUTION: proposal accepted

Ojan: Do we want to address visibility: collapse

<TabAtkins_> fantasai: the problem with using display:none to dynamically show/hide elements...

<TabAtkins_> fantasai: ...is that you really only want to take thing out-of-flow in one dimension (the main axis).

<Bert> (Example of 'visibility: collapse' in tables: http://www.w3.org/Style/Examples/007/folding)

<TabAtkins_> fantasai: You can't do that with display:none, but visibility:collapse is *supposed* to solve this in tables. It does a bad job, but we cant do it right.

(example was of a panel with collapsing panels)

<TabAtkins_> dbaron: I think it doesn't work well in tables because it hasn't been solved right yet.

<TabAtkins_> dbaron: Because if you have more space for the other things, they can be smaller in the other dimension, so they'll still change size.

<TabAtkins_> fantasai: Tables also have the problem that row/col spans get clipped oddly by collapse.

<TabAtkins_> ojan: My concern with this is that this is sort of a more generic thing. Why doesn't this work on lists (hiding, but still incrementing counters).

<TabAtkins_> fantasai: I'd like it to work there.

<TabAtkins_> ojan: Right, but there's backwards compat issues. So let's ignore collapse, and solve it properly with a new property or value.

dbaron: What's the problem with lists?

that's not solved by display: none?

TabAtkins: Preserving counters.

fantasai: Also contribution of the width to the parent's intrinsic size

TabAtkins: Also, running animations.

Steve: what happens if I set height to zero

fantasai: you also have to turn off padding, border, margins, box-shadow, etc. etc.

Ojan: So it's dead in the water to make visibility: collapse; work on block elements, I presume?

dbaron: I don't know, maybe not

Molly: visibility: collapse isn't taught
...

fantasai: Goal is to make it not show up, just like display: none; except without some of its problems

Bert asserts that you'd want to leave extra space so that the content after the list stays the same place

fantasai doesn't understand what we're arguing over anymore

dbaron: sounds like this is unresolved

<TabAtkins_> scribenick: TabAtkins_

howcome: multicol is in CR. impls are coming along.
... But there's one area i've discovered wehre we don't hav einterop
... the break-before/after/inside properties

<howcome> http://www.w3.org/TR/css3-multicol/#break-before-break-after-break-inside

howcome: Basic question i need an answer for.
... Applies to both column and page breaks.
... Say you have an element, the first in a page or column. And you set break-before on it.
... Should you apply it (forcing a new break), or just leave it, since it's already the first element.
... I think we should do the latter.
... For both pages and columns.

fantasai: For pages, you sometimes want blank pages, but you don't want *arbitrary* extra blank pages. Usually you want to start all chapters on the left page, or something.

glazou: Sometimes you do specifically always want, say, 1 blank page before chapters.

fantasai: You can do that by using ::before or similar and give it a sufficient height (but no content) to push the rest of the content down.

howcome: 2 out of 3, roughly, do it the way I want.

<ChrisL> <div class="notes" style="page-break-before:always;background-image:tpib.png"/>

howcome: The others force a new break.

<ChrisL> s/tpib/tpilb/

glazou: So the proposal is to *not* create a blank column when the first element in a multicol has break-before:always.

RESOLUTION: break-before:column won't force a blank column when the element is the first in the column.

fantasai: For pages, there are use-cases where you want to feed the blank pages, there are larger use-cases where you *absolutely don't* want that.
... So we should use that as the default, and possibly address the "force blank pages" later.

RESOLUTION: Pages work the same as columns - an element at the to pof the page with break-before won't force a blank page.

howcome: Now, <div><div></div></div><style>div { break-after: all; }</style>
... Two breaks? Or do they collaps?

fantasai: I think they do collapse. The spec seems to imply that as well.

TabAtkins_: And it's consistent with the decision we just made.

alexmog: I don't think any browser currently has that behavior.

fantasai: I intend to fix that in Mozilla.

alexmog: I think all browsers collapse -after breaks, but not -before breaks.
... Things like the <html> element shouldn't count as "content" before the element, forcing a break. Same with display:none elements.

fantasai: For <div></div><div></div>, we shouldn't collapse - breaks shouldn't collapse through.

<fantasai> corrected example: <div>...</div><div/></div>...</div>

szilles: I'm surprised at this. I would think it would be simpler to always honor the breaks, not collapse.

alexmog: Say you have an <h1>, the first thing in the document, and you set break-before on it.
... But it's *not* actually the first element. <html> and <body> precede it.

szilles: Isn't that consistent with our previous case? If the <h1> is at the top of the page...

<fantasai> TabAtkins: This is a different case

<fantasai> TabAtkins: In this multicol case, the <div> is literally the first thing on the page

<fantasai> TabAtkins: In the other case, the <h1> is not the first thing on the page, it's wrapped by a <body> and an <html>

<fantasai> szilles: Define that as being at the top of the page

<fantasai> Alex: Orphan control shouldn't .. if you have a region with only room for one line, and we have an element with orphan that has 3 lines

<fantasai> alex: we're currently going to move that to the next region because we're not at the top of the page

<fantasai> alex: You have a long enough paragraph, multiple lines

<fantasai> alex: starts in a region which can fit just one line

<fantasai> alex: which is ok for titles

<fantasai> alex: You want that one line to still be in that region, even though with orphan control will want to keep it with the rest of the parent

<fantasai> alex: The resason these cases are related, is if break-before and break-after are intepreted as I think in the spec

<fantasai> alex: they're not "make sure there's a break here", it's "make sure this is the first thing on the page"

<fantasai> alex: For both widow/orphan and breaks, you're still looking at whether you're the first thing on the page

<fantasai> alex: opening tags don't count as making you not at the top of the page

<fantasai> szilles: That would just fall out of the deifnition, which is make sure this is the first thing on the page

<fantasai> howcome: ...

<fantasai> howcome: <chapter><section></section.</chapter>

howcome: You'd like to break before/after both the sections and chapters.

<fantasai> howcome: You want each chapter to start on the first page, and each section to start on the first. You want to set break-before

fantasai: 2.1 says that when determining breaks, you look at the break properties of all the elements that meet at the given margin.
... It's pretty vague, unfortunately.

alexmog: page breaks don't prevent margin collapsing, though...

<alexmog> http://www.w3.org/TR/CSS21/page.html#forced

TabAtkins_: Specifically, the definition of "top of a page" is underdefined. Does a marging or border on a parent make you no longer at the to pof a page? (The correct answer is no.)

<fantasai> dbaron: It needs to be defined in a whole bnch of cases. Frex Mozilla has mTopOfPage, which deals solely with the possibility of somethng not fitting -- it lets us know

<fantasai> dbaron: if we have made any progress in putting things on the page, so that we don't keep breaking and placing no content

<fantasai> dbaron: For that border does count

alexmog: Having <body> as your parent, even with ??? is honored.
... If you look at break-after, which is supposed to be consistent with break-before, all browsers collapse break-after.

szilles: Isn't that the same rule/difficulty in determining if something is at the end of the page?

alexmog: Yes.
... [some sectoin] has a very simply rule that just says a forced break occurs when any elements contributing to the current margin have a forced break.
... So you go and do normal margin collapsing, then look at the result.

<fantasai> ...

<fantasai> alexmog reads from CSS2.1 spec

fantasai: It wouldn't have been written with more than one element if collapsing wasn't meant to happen.

<fantasai> s/one/two/

howcome: So we can just clarify 2.1 if it' snot fully clear.

szilles: Doesn't the margin definition break if you put a border on <chapter>?

TabAtkins_: Yes, and that's bad.

dbaron: What happens if one says 'left' and the other says 'right'?

howcome: I say you choose whichever one grants you the most pagebreaks.

fantasai: When collapsing breaks there's nothing "between" your breaks. I think you should choose the last one, because it's the one closest to the next content.

howcome: I'd like to have a resolution because we're in CR, and we need testcases written.
... I can live with the last one winning if there are conflicts.

fantasai: The spec is pretty clear that a series of page breaks should never generate more than one page break in series.

howcome: Okay, so collapsing works. Do borders stop break collapsing?

alexmog: They block margin collapsing, so.

howcome: Can't we just lean on margin collapsing's rule?

fantasai: I don't think there's *ever* a use-case for having a border around a blank page with this.

alexmog: the 2.1 definition is based on margin-collapsing.

<fantasai> Florian: We should prioritize authors over implementations, and authors don't want a blank page with just a border.

alexmog: And if we can avoid changing the very complicated margin-collapsing, that's good.

<fantasai> szilles advocates for just coming up with a good definition for top-of-page

<fantasai> szilles: Definition is if you haven't put any content on the page, then you're at the top. And borders aren't content.

<fantasai> TabAtkins: This is still wayyy simpler than margin collapsing. There's no negatives, no zer-height elements that collapse through, none of that.

<fantasai> howcome: I think there's some kind of consensus here.

<fantasai> RESOLVED: page-break-before doesn't create a break if you're at the top of the page, where at the top of the page means no content has been placed. Borders do not count as content.

<fantasai> Zero-height content counts.

<fantasai> as content

<fantasai> dbaron: So placing an empty block counts, but placing start of a block does not count.

<fantasai> dbaron: Alternative def is placed either a non-phantom line box or a non-replaced block with non-zero height, or anything other than something that goes in a line box, or ...

<fantasai> TabAtkins: Can we just say line boxes is all we care about?

<fantasai> dbaron: tables? replaced blocks?

<fantasai> s/, or .../and isn't a non-replaced block/

<fantasai> TabAtkins: Why are we allowing ... collapsed through?

<fantasai> dbaron: Because alex waned it

<fantasai> Alex: I really like CSS2.1 definition because it covers lots of cases in just 2 lines

<fantasai> howcome: So we have one proposal which is 2.1, based on margin collapsing

<dbaron> I'm fine with the 2.1 definition

<dbaron> s/waned/wanted/

<fantasai> howcome: And then another, perhaps simpler, definition

<dbaron> s/and isn't a non-replaced block/, or something that doesn't go in a line box and isn't a non-replaced block/

<fantasai> howcome writes out the definitions

<fantasai> dbaron: One thing that seems weird is that you have start of a block, that's ok, and end of a block, that's ok, but start *and* end of block, that's not ok

<fantasai> ...

<fantasai> TabAtkins: The break-afters generate a break

<fantasai> TabAtkins: The break-befores don't generate a break: they're already on a new page

<fantasai> fantasai: The thing that's weird is collapsing anything through the content area of an element. We do that for margin collapsing, and its weird. We should not do that here.

<fantasai> alex: I have a problem with not counting the border as content

<fantasai> alex: My margin will be after that border, and while I'm asking to be the first thing on the page, I'm not really

<fantasai> TabAtkins: I think the potential downside of where that might be confusing is less bad than having an entirely blank page with nothing but a border on it.

<fantasai> fantasai: You're actually not required to print pages that have only backgrounds and borders on them

<fantasai> howcome: It seems you feel quite strongly about this, Alex.

<fantasai> howcome: Let's take a quick straw poll.

<fantasai> A: alex

<fantasai> B: steve/fantasai/tab

<fantasai> jj: A

<fantasai> alex: A

<fantasai> koji: abstain

<fantasai> Markus: abstain

<fantasai> Tantek: abstain

<fantasai> Steve: B

<fantasai> Alan: abstain

<fantasai> abstain

<fantasai> Florian: B

<fantasai> ert; abstain

<fantasai> ....

<fantasai> lots of abstain

<fantasai> howcome: we can collapse all the abstain

<fantasai> Rossen: A

<fantasai> dbaron: A

<fantasai> sylvaing: abstain

<fantasai> arronei: A

<fantasai> Tab: B

<fantasai> fantasai: B

<Bert> s/ert;/Bert:/

<fantasai> smfr: B

<fantasai> molly: B

<hober> hober: b

<fantasai> molly: The empty <div> is there. If we're dynamically generating things, it should have an effect

<fantasai> fantasai^ explains the two options

<fantasai> now howcome is explaining why we're collapsing at all

<fantasai> Alex: If you look at continuous media, where instead of page-break you have a large margin

<fantasai> alex: e.g. 3em margin

<fantasai> alex: whatever comes after margin is held together by the results of margin-collapse

fantasai: If you're collapsing through this element, where is this break happening?
... If you have a bunch of break-afters, and you collapse them, and you break the page, the margins that were there get truncated.
... But after a forced page break, you keep margins at the top.
... If you have an empty div, and you have set break-before and after on it, and the preceding and following div also have breaks, which page is the middle <div> contributing to?

dbaron: And more importantly, which page is the empty div on?

alexmog: Where does it say that margins are truncated after the break?

howcome: We resolved on that.

dbaron: [explains the 2.1 spec for it]
... And this assumes that breaks exist *between* block-level margins, rather than being stuck somewhere *inside* of collapsed margins.

<dbaron> quoting 13.3.3 point 1 and the note following

<fantasai> jj: A

<scribe> new straw poll!

<fantasai> alex: A

<fantasai> steve:B

<fantasai> Florian: B

<fantasai> Bert: A

<fantasai> Brad: B

<fantasai> hober: B

<fantasai> smfr: B

<fantasai> Kim: B

<fantasai> Molly: B

<fantasai> Rossen: B

<fantasai> dbaron: B

<fantasai> arronei: A

<fantasai> TabAtkins_: B

<fantasai> TabAtkins_: B

<fantasai> glazou: B

<dbaron> s/TabAtkins_/fantasai/

s/TabAtkins_:/fantasai:/

<dbaron> s/fantasai/TabAtkins/

<fantasai> 4 A, 12 B

<fantasai> ChrisL: B

<fantasai> -> 13 B

<fantasai> RESOLVED: B

<fantasai> ACTION: fantasai to put proposal B for page-break collapsing into specs [recorded in http://www.w3.org/2011/10/31-css-minutes.html#action05]

<trackbot> Created ACTION-393 - Put proposal B for page-break collapsing into specs [on Elika Etemad - due 2011-11-07].

<fantasai> dbaron: We should errata 2.1

<dbaron> alex: can we get it written up first?

<fantasai> sylvaing: Column boxes define a containing block, right?

<fantasai> sylvaing: What if my columns are balanced and I have a percentage height?

<fantasai> dbaron: If it's auto height, it's auto-height

<fantasai> dbaron: The column boxes all occupy the full height of the multicol box

<fantasai> dbaron: They should have the same implicit height

<fantasai> sylvaing: Don't they adjust when you balance

<Bert> ACTION: bert to create issue against CSS 2.1 corresponding to ACTION-393. [recorded in http://www.w3.org/2011/10/31-css-minutes.html#action06]

<trackbot> Created ACTION-394 - Create issue against CSS 2.1 corresponding to ACTION-393. [on Bert Bos - due 2011-11-07].

<fantasai> RESOLVED: percentage in block dimension is computed relative to multi-col element

GCPM

<fantasai> howocme: This is what I showed last night.

<fantasai> howcome: A few other changes we need to go through.

<fantasai> howcome: WD is a year old.

<fantasai> howcome: One thing that left GCPM since then is hyphenation

<fantasai> howcome: We should do an updated WD

<fantasai> howcome: A couple other things

<fantasai> glazou: Markus has shown me horizontal navigation in a document that is a little bit in conflict with your proposal

<fantasai> howcome: I don't think it's in conflict, they're going in the same way

<fantasai> Markus and howcome seem to be ok with the situation

<fantasai> howcome: I'm not tied to the syntax, but I think it shoudl be declarative as you say

<fantasai> markus: Declarative is good, but you also need JS access

<fantasai> howcome: First issue is with leaders

<fantasai> howcome: Bert brought up this point

<fantasai> howcome: The issue being that he wanted to have control over alignment of leaders

<fantasai> howcome: If I understood correctly, Bert, you wanted to create a leader that's an arrow

<fantasai> howcome draws: ABC ------------> 1

<Bert> examples of leaders (hacked, of course, but showing the way I want them)

<fantasai> howcome: In order for this arrow, which is in the generated content,

<fantasai> howcome: to make this visually make sense, Bert wants the point of the arrow to connect with the line

<fantasai> howcome: So that you don't get that effect *draws an arrow where the head is broken from the body*

<fantasai> ChrisL: That assumes the horizontal lines match up with the arrows

<fantasai> Bert: In the Symbol fonts they do

<fantasai> howcome: the idea is to add a second argument to the leader function,

<fantasai> howcome: I think these are the values you need: 'start', 'end', 'center', 'space', 'pattern'

<fantasai> howcome: pattern is to make the dots align across lines

<fantasai> glazou: 'space' should be 'stretch'

<fantasai> fantasai: Stretching implies stretching the glyph. background-repeat uses 'space'

<fantasai> howcome: You want these leaders to align. I think this is the most common use case.

<fantasai> szilles: Don't understand where the space is added.

<fantasai> dbaron: You put as many characters as will fit. In normal case you right-align them

<fantasai> dbaron: In space case, you insert spaces between the leaders

<fantasai> szilles: Need to be clear about whether its between all the characters or between each string

<fantasai> Bert: Not the way it works in TeX, but it's another option

<fantasai> Bert: The leader unit is a fixed size, doesn't chnage size

<fantasai> Bert: Can put space before/after, both, etc. but not inside it

<fantasai> Tantek: Aren't leaders like border-images?

<glazou> s/'space' should be 'stretch'/'space' will mean whitespace in web author's mind, please use something else like stretch (just an example)

<fantasai> Tantek: why not use images

<fantasai> szilles: Because the common case is to use glyphs

<ChrisL> typographers also see decorations as glyphs

<fantasai> fantasai: might want both characters and images

<fantasai> fantasai talks about matchng the dots to the dots in the font, in size, postion, and shape

<fantasai> szilles: We've talked about a need for characters, there might also be a need for images

<fantasai> molly: I think space, which goes characters out to available space, and justification which fits inside the containing block

<fantasai> ????

<fantasai> molly: What I interpret that as meaning space out the chraacters to take up the width

<fantasai> howcome: That's right

<fantasai> howcome: The quesiton is between all characters or only where the repetition is

<fantasai> szilles: Why not have two values

<fantasai> fantasai: space and justify

<fantasai> fantasai: space like border-image and background-repeat

<fantasai> ?: letter-space and pattern-space

<fantasai> molly: justify makes sense

<fantasai> molly: This addresses both issues

<fantasai> howcome: Does anyone need center?

<fantasai> Bert: Sometimes you want as much space before the leader as well as after

<fantasai> dbaron: Centered absolutely or centered individually?

<fantasai> Florian: We're resolving to split the space into two, and not remove any other value

<fantasai> some confusion around everything

<tantek> (try resizing)

<tantek> #tablesabuse

<fantasai> howcome puts in string-space and letter-space

<fantasai> bikeshed pattern -> align

<fantasai> fantasai: I'd also drop the comma and use ||

<fantasai> fantasai: just like in properties

<fantasai> Bert: One more about leaders, but maybe not so easy to solve.

<fantasai> Bert: How to make double-ended arrows

<fantasai> fantasai: Just put three strings: "start" "middle" "end"

<fantasai> TabAtkins: image-resolution is in css3-images, so should remove from here

<fantasai> howcome: ok, done

<fantasai> szilles: One other catch with alignment

<fantasai> szilles: In Indic languages, the leader aligns with the hanging basline

<fantasai> szilles: In Japanese it would be centered

<fantasai> fantasai: That should be handled in the fonts

<fantasai> szilles: The leader needs to be aligned to the relevant baseline.

<fantasai> szilles: That may fall out

<fantasai> szilles: Just want it noted

<fantasai> howcome: Nothing changed in ... various sections ....

<fantasai> howcome: Paged Presentations

<fantasai> howcome: This is basically what I demoed yesterday, where we use the overflow property to set the axis onto which we put out these pages

<fantasai> howcome: They could be analyzed and split into two, and we could have multiple properties for them

<fantasai> howcome: We did that at some point in our implementation, but it creates many possibilities

<fantasai> howcome: that we aren't really going to use

<fantasai> howcome: So instead we have four values that cover the needs we have found

<fantasai> howcome: there might be others

<fantasai> howcome: not tied to syntax, but we like the functionlity

<fantasai> howcome: the -controls bit adds the UI

<fantasai> howcome: native UI for paging

<fantasai> szilles: I'm concerned that it's not as standardized as scrollbars are

<fantasai> howcome: It's like HTML5 controls for video

<fantasai> glazou: that's in the markup

<fantasai> alex: ... overflow paginator, could be x and y

<fantasai> howcome: Could split these into 2 properties. Paged thing could be on 2 oveflow, and the others on a diferent property

<fantasai> howcome clarifies that x in paged-x is about how the pages connect, not which direction of overflow is affected

<fantasai> glazou: I'm very concerned about the controls bit

<fantasai> Florian: Does the first bit forbid the UA to have controls?

<fantasai> howcome: Alex asked, does touch work both places?

<fantasai> howcome: This just adds visual controls

<fantasai> dbaron: In the simplest case it could even be a scrollbar, though probably not the best idea, but it could be

<ChrisL> so the distnction is that the controls take up space

<fantasai> howcome: We have overflow: scroll;, so we are referring to controls already

<fantasai> fantasai: In scroll vs auto, we're distinguisshing whether the controls are visible when there's no need to scroll, not whether the UA should put controls at all when there is overflow to scroll to

<fantasai> dbaron: More similar to hidden

<fantasai> molly: Point out that if the controls are UA-dependent, could be a problem -- authors will want to style it

<fantasai> Bert: When we introduced marquee, we added overflow-style and had it as a value of overflow-style

<fantasai> Bert: This seems more like additional values for overflow-style

<fantasai> Tantek: overflow-style: marquee-paged

<fantasai> Markus: In the first case (paged-x) you still want some indication of where you are

<fantasai> Markus: The default shouldn't be nothing.

<tantek> where's Tapas when you need him

<fantasai> dbaron: There are 2 options, in some sense there's no default. You can choose with or without controls

<fantasai> howcome: This is where we've built a UI through the dom. These controls have been made by the page (shows demo) whereas these are made by the UA

<fantasai> szilles: I'm still confused about what "this" is that you say should be in CSS

<fantasai> Adobe: In Acrobat the controls appear on hover

<fantasai> howcome: you can choose whether UA gives controls or whether author provides controls

<fantasai> fantasai: What if the author assumes you have a swipe interface for paging, and doesn't provide controls, but I don't have that interface? Then I'm stuck.

<fantasai> glazou: When you use the overflow property, you just say that the overflow should be visible in some way. You don't make any provision about the means.

<dbaron> I disagree with Daniel.

<fantasai> Markus: Here I'm showing you a similar solution using regions and exlucions

<dbaron> I don't think saying there are "controls" is too constraining.

<fantasai> Markus: You have a template mechanism that handles overflow.

<fantasai> Markus: At the bottom there is a little indicator of where you are and how many pages you have

<fantasai> Markus: If I use the mouse, I get a scrollbar

<fantasai> glazou: Here you are stopping the scrolling between two pages

<fantasai> (markus is demoing)

<fantasai> markus puts some experimental -ms- snap properties

<fantasai> markus: Now it snaps between pages

<fantasai> markus: But you still get a progress indicator, so you know where you are

<fantasai> markus: Beauty of this approach, based on regions, it's a simple JS templating model.

<fantasai> markus: You can inject animations, etc. etc.

<fantasai> markus: Not saying howcome's idea is a bad idea, but this brings more powerful

<fantasai> Tantek: Can we go back to howcome's demo

<fantasai> Tantek: You mentioned that simple values etc.

<fantasai> Tantek: I'm wondeirng how does that interact with overflow-x and overflow-y

<fantasai> Tantek: I know Opera supports those.

<fantasai> Tantek: If you've figured that out, I'd love to understand that interaction

<fantasai> howcome: These properties only belong on overflow shorthand

<fantasai> Tantek: That's why I think they should go on overflow-style

<fantasai> howcome ...

<fantasai> fantasai: I agree it should go in overflow-style

<fantasai> dbaron: This changes the layout model

<fantasai> dbaron: It's not just changing how we get to the overflow

<fantasai> fantasai: I have a question for Markus: what happens when you print?

<fantasai> Markus projects:

<fantasai> body {

<fantasai> overflow-x: auto;

<fantasai> overflow-y: hidden;

<fantasai> -ms-scroll-snap-type: mandatory;

<fantasai> -ms-scroll-snap-points-x: snapInterval(...)

<fantasai> }

<fantasai> Markus: In general the basics of how this app runs, it's just a simple page that brings in other html pages as templates

<fantasai> markus: We also have a default overflow template

<fantasai> markus: Just a little bit of JS to make this stuff work

<fantasai> glazou: little bit?

<fantasai> markus shows template pages

<fantasai> markus: Place my items, grid

<fantasai> Markus: What I showed you at the end is playing with this snap thing

<fantasai> Markus: You can snap after one page, multiple pages, define ranges etc.

<fantasai> Markus: We presented at the build conference, sdk out there, want to bring th WG as a propsoal

<fantasai> glazou: So this only works with JS?

<tantek> LOL - Håkon's pagination proposal is already in the media: www.macworld.com/article/163317/2011/10/opera_cto_kill_the_browser_scroll_bar.html

<fantasai> fantasai: I don't mind having JS interact with CSS, but I don't want us to build layout models here that require JavaScript in order to work.

<tantek> (and http://dvice.com/archives/2011/10/creator-of-css.php )

<fantasai> Markus: You can do interesting animations

<fantasai> Markus: When we started thinking about pagination, we started with something ismilar to howcome's model, but thought it would be better to have .... to create a better magazine-type experience.

<fantasai> hober: ...

<fantasai> howcome: I encourage you to add pagination to regions

<fantasai> alex: Pagination should be part of regions

<fantasai> howcome: Regions should know how to work with pages

<fantasai> szilles: I agree with fantasai's statement that layout models shouldn't require JavaScript, but also good to define events and things to add more

<fantasai> glazou: Agreed, but the basic thing howcome demoed shouldn't require JavaScript

<fantasai> sylvaing: Right, it should be optional

<tantek> pagination events would be useful

<fantasai> howcome shows his api

<fantasai> szilles: I might want to ask questions about pages, like what links are on this page

<fantasai> howcome: I think that's reasonable

<fantasai> howcome: I object to you calling this a low-end feature, markus.

<fantasai> howcome: I can recreate the Economist's layout almost pixel perfect with this

<stearns> Alex's comment was that pagination should *not* be part of regions

<fantasai> BradK: Howcome's solution, the UA cna provid ethe UI for how the pagees get turned

<fantasai> bradk_: So you can even hav an ibook like experience, where it's curling and everything. Could be a high-end kind of experience

<fantasai> florian: high-end from control of the user, not the author (?)

<fantasai> bradk_: I consider an advantage, don't have to relearn how to turn pages on every website

<fantasai> Alan: I think whatever we build for pagination should work with multicol, work with regions, shoudl wirk without either

<fantasai> Alan: Could see this for slides

<fantasai> Markus: As soon as you want more flexibility on what thigns look like, you need regions

<fantasai> bradk_: Scrollbars are the same every page you're at, unless the author does somethng special

<fantasai> bradk_: I think that's good, so you don't have to figure out how to turn pages.

<fantasai> Szilles: If we're going to do what Brad just said, we should agree on what the compones are

<fantasai> szilles: My Kindle can do more than go back and forth between pages

<fantasai> szilles: A bunch of things ppl expect when paging things

<fantasai> szilles: Come up with some expectation of what the controls should be

<fantasai> szilles: controls is too open ended

<fantasai> [szilles says stuff about bookmarks etc]

<fantasai> molly: I agree.

<fantasai> molly: Need consistency, and say explicit about how it needss to be done

<fantasai> hober: HTML5 doesn't say much about what the video controls should be

<fantasai> howcome: Depending on what the device is, might have different controls

<fantasai> Florian: Say what capabilities it has

<fantasai> molly: I want to step back a moment,I understood that if you use these features and allow the UA specific ontrols, that you wil be able to style those ocntrols

<fantasai> Florian: If you want to style it, you build it yourself.

<fantasai> molly: ok

<fantasai> hober: Ua could provide some hook into its controls, but that's up to the UA

<fantasai> molly: As long as ppl can create their own controls

<fantasai> Bert: As longas I as the user can override what the author does

<fantasai> Bert: I want consistency across pages. I choose my browser.

<fantasai> fantasai: If the author says, don't put controls, and builds his own out of JS, and the user is lke "I can't deal with these weird controls, I want my own controls", how do you deal with that?

<fantasai> Florian: Turning on the UA controls is easy. Killing the author controls is not so much.

<fantasai> szilles: Also need ot make sure ther eare screenreader APIs for this.

<fantasai> discussion of accessibility apis and what they're capable of

<mmielke> Links to the Regions based demo (runs on win8 developer preview): http://code.msdn.microsoft.com/windowsapps/Dynamic-Region-Templates-94bc9c95

<fantasai> molly: When you're looking at this content anyway, the ocntent is linearized in your core document

<fantasai> szilles: With regions you can mix streams

<fantasai> alex: I think this should be a display property

<fantasai> alex: If it's overflow property, it applies to everything. But paging a flexbox doesn't make sense.

<fantasai> alex: All other kinds of layout that support overflow don't need to support paged overflow

<fantasai> plinss: Don't see why you can't paginate flexbox

<fantasai> howcome: I'd really like to publish another WD of GCPM.

<fantasai> howcome: We haven't gone through everything, so we can have big disclaimers about syntax and everything

<fantasai> howcome: But I'd like to get out another WD. First for updates to other things. But second there seems to be consensus that we want to work on this.

<fantasai> glazou: Don't have consensus, have interest

<fantasai> glazou: So provided you document all the issues and comments.

<fantasai> glazou: It's only a WD and we have interest in the feature

<fantasai> szilles: I'm def interested in the feature, but not sure where it belongs

<fantasai> fantasai: It can start here, and then we'll see where it goes. Just like everything else.

<fantasai> TabAtkins: Move counter styles to css3-lists? most is already in css3-lists. Willing to take on the next thing

<fantasai> dbaron: I think there's a bunch of things in this spec, and not a whole lot of interest in other things in the spec

<fantasai> fantasai: we're doing that already

<fantasai> dbaron: So we're going with the model that everything we want will go out of it?

<fantasai> howcome: Like John said, I don't think this will ever go to REC

<fantasai> s/this/this module/

<fantasai> glazou: Any objection to publishing?

<fantasai> RESOLVED: Publish CSS3 GCPM as soon as all edits are made

<fantasai> glazou: Reminder, lot of joint meetings tomorrow, not necessarily in this room

<fantasai> glazou: Also FXTF on Thursday

<fantasai> glazou: Start here tomorrow.

<fantasai> glazou: We will discuss CSSOM with Anne at 9am

<fantasai> fantasai: jdagget, kojiishii and I will be having a joint meeting with the UTC on Thursday

<sylvaing> scribenick: sylvaing

CSSOM

annevk: the CSSOM is a collection of various CSS features exposed through script
... such as alternate stylesheets, stylesheets themselves
... and a new part is CSS values which is very new
... we are now waiting for implementation experience for CSS values

florian: we had talked about defining serialization

annevk: nothing new at this point

fantasai,annevk: we had talked about defining the serialization of basic types in a Serialization module

fantasai: most of them were in CSS2.1 or should be new units in css3-values and Color

jdaggett: there may a problem with the way we've modularized; some modules need to rev often than others. CSSOM is one of those

Tab: some specs need to be 'living' ?

fantasai: that was the case for many modules. hence the modularization

jdaggett: if I add an at-rule I need a DOM interface so I'm adding things that should be in the OM

annevk: if you add an at-rule you should define all the related OM pieces in the same place

florian: the problem we have right now is bootstrapping. we don't have a 2.1 for serialization

s/florian/fantasai

fantasai: until we have that we will be discussing process

glazou: we're also going to talk about the OM forever until we fix its issues and implement the fixes
... we need a better OM

tantek: I agree we need a foundational OM spec.

<fantasai> +1

tantek: just like HTML went through a painful process of defining an OM in sync with content out there. Starting with a known feature set would be easier and establish a baseline

<fantasai> tantek: Instead of redrawing module lines, we should start by creating an OM for CSS 2.1

jdaggett: we do not have a consistently defined DOM interface. some modules define new at-rules but implementations may be using different rule constants which should be coordinated across specs
... there is no one looking at these features from an OM perspective. It's up to each editor and each editor's level of OM experience e.g. some modules will not define exceptions correctly
... so specs are inconsistent

tantek: I suggest the common reference baseline would be a 2.1 OM

jdaggett: how does that help with new features

fantasai: like non OM features, most new OM features derive from existing features in 2.1 and you would have patterns to base new interfaces on

jdaggett: the pattern for what you have to do to specify a new at-rule is not defined; I'm not sure a 2.1 OM defines it. how is that different from what we have now ?
... I think we need more: at least a set of how-to guidelines e.g. if you define a new at-rule, these are the things you need to specify

tantek: we agree on goals, we're only discussing how to get there

jdaggett: I don't think we even have consensus on issues such as prefixed at-rules and how this relates to at-rule constants

glazou: this should definitely be specified

tantek: we should reach a bar where each module should define its DOM

<fantasai> Proposal: Modularize CSSOM. Break it up into a a Serialization module, a Values module, an At-Rules module, a Media Queries module, etc.

tantek: keeping things separately did not help HTML

dbaron: there are modules how define their own OM e.g. Transitions (events), Animations (OM), Fonts, Conditional....

dbaron,annevk: Transforms has a value type but we agreed to deprecate the CSSValue type it uses

tantek: I think we need something that is up to date with 2.1

dbaron: part of the base problem is that DOM L2 Style has a number of features that are wrong, and a number of things we agreed to change but never fixed
... we need to define this core baseline so we can build on top of it

annevk: as far as values, we deprecated the 2003 model but never replaced it
... I didn't want to spec out the new model fully until we at least had some implementation experience with it

tankek: is there interop among browsers for 2.1 CSSOM ?

dbaron: what do you mean by 2.1 ?

tantek: what is in Gecko, Webkit, Trident today ?

dbaron: I don't know if it's that that interoperable?

annevk: I don't see how reorganizing is going to help us vs. implementors working on it.
... there isn't even much discussion

dbaron: also, authors don't use the OM that much

tantek: isn't it a chicken-and-egg problem; they don't because they can't
... Tab was complaining about how many obsolete drafts we have. we have this problem here too e.g. DOM L2 Style.
... I'd like to see something that reflects the interoperable state of the world

<dbaron> dbaron: I think authors don't use the OM much, even what is interoperable. Authors tend to use the model that styles are static and they dynamically change the content-- and I tend to think that's a good thing.

dbaron: if there isn't a lot of demand for it, should we spend time on it ?

<fantasai> http://dev.w3.org/csswg/cssom/

tab: I know that there is demand for a new value based om that wouldn't be string-based. It's a popular author request that is currently done through libs like jQuery
... we know that there is a use-case in that area

dbaron: yes, i've seen author demand for this, as well as for variants of computed style as well as some author demand for the set of matched rules for an element
... I can't recall authors asking for poking through rules inside a stylesheet

tab: that is useful for CSS polyfills

annevk,dbaron: except the features you want to polyfill are dropped

fantasai: I'd like to document what we have right now
... and the new interfaces would be in a separate document
... and we can move the bit that's implemented in CR and beyond

kimberly: we as implementors are looking for guidance; we need a document that reflects what browsers do in order to build compatible devices/platforms

howcome: are we interested in investing this kind of effort ?

<fantasai> [insert^ discussion about the fact that DOM Level 2 Style is on /TR and has not been obsoleted by anything]

<fantasai> sylvaing: It does keep coming back.

<fantasai> glazou: But it keeps coming back. We've been discussing this since 10 years ago.

<fantasai> glazou: Anne invested a lot of time in this spec cleaning it up

<fantasai> glazou: Form an implementation POV, we're almost exactly at the same point

<fantasai> dbaron: There's a bunch of things in anne's spec that have been implemented. It's just not the core stuff

dbaron: I think there are things in the spec that have been implemented. but a number of things have not been

<fantasai> discussion of poking around the style sheet

discussion of how many people need editing functionality

alan: do we need a testsuite to get implementors interested ?

<fantasai> sylvaing: There's enough pain that this topic keeps coming back, but not enough that implementers are investing in it

tantek: since we agree to have obsoletion noticed in old modules that aren't maintained, I think we should do that for DOM L2 Style and link from the latter to CSSOM

bert: but then there is nothing stable anymore

tantek: but that is reality and would be honest

annevk: that would be a service to the community, I think. They would at least know what we're working on now

bert: it's better but not enough

<fantasai> annevk: we should at least have a link to the obsoletion email you sent in 2003; adding a link to the CSSOM would be helpful, but not critical imo

glazou, jdaggett: the specs are not understandable or usable hence the attraction of jQuery as a way to use the OM

jdaggett: is it OK to mark specific sections as obsolete at least ?

glazou: yes

jdaggett: so CSS values in DOM L2 Style in marked invalid, not the entire spec

hober: that can also be marked at the top

glazou: I don't want the entire document to be obsoleted

plinss: is the problem unaware of the Editor's Draft ? is that the problem ?

<fantasai> various people giving examples of this actually being a problem

dbaron: there are 2 threads here; the value API and the representation of style sheets e.g. at-rules

glazou: I don't understand why we don't have a requirements document for this

<fantasai> RESOLVED: Add obsoletion notice stating which sections of DOM Level 2 style are obsolete, links to Bert's obsoletion notice, and links to the CSSOM editor's draft

RESOLUTION: add a notice to the top DOM L2 Style indicating portions of the spec are obsolete linking to Bert's email and linking to CSSOM. Also, the specific obsolete section of DOM L2 Style must be marked as such

<fantasai> ACTION: Tab to Draft note on DOM Level 2 Style [recorded in http://www.w3.org/2011/10/31-css-minutes.html#action07]

<trackbot> Created ACTION-395 - Draft note on DOM Level 2 Style [on Tab Atkins Jr. - due 2011-11-08].

fantasai: once we agree on the draft notice, we can resolve a PER

dbaron: the things people do with jQuery relates to the value API; editing tools need both the value API as well as the stylesheet traversal interface. The latter is not that hard but the current specs are inconsistent and poorly written, but 80% right
... we decided to throw out the value API and rewrite it but the new API is a draft that no one has implemented

<fantasai> annevk: Only part of the values API is there

<fantasai> dbaron: If someone tried to implement it, what would happen?

sylvaing: does one need to implement it in the engine or could it be experimented with in JS ?

<fantasai> jdaggett: If it's not a big API...

annevk: it could be done in JS

<fantasai> dbaron: It's a pretty big API

<fantasai> jdaggett: It seems we have two modules here. I keep hearing that we need something in a firmer state, and the Values API is not in that state

<fantasai> annevk: I don't think we need to split the draft.

jdaggett: I think the stylesheet traversal API has more impact on new features

dbaron: it depends on the feature. if we implement the new values API, this would impact CSS3 Fonts features e.g. font-feature-settings would need a whole object model

jadaggett, dbaron: there is no consistency of design among the at-rule definitions across modules

annevk: shouldn't that be solved by review ?

tab: we should have guidelines before review

dbaron: the OM for keyframes rule looks different from what's in 2.1 but it was already implemented so I followed the same model.

<anne> I have to go in four minutes

dbaron: as far as we can tell, it's unclear that the people who use these interfaces care about these inconsistencies

<fantasai> Florian: The people who care do not give sufficient feedback

dbaron: one of the ways we judge interest in things is based on feedback on obvious problems

glazou: and maybe they don't have to comment because there are shims like jQuery which deal with the problem

<fantasai> plinss: If something is bad enough, people look at it and decide it's way to unstable, way too much of a mess, to comment on

dbaron: that is the values API, not the stylesheet interface. they're not the same thing.

fantasai: I edit a lot of specs. I don't know what I need to put in my spec about serialization, OM, values API. I don't know what to do in CSS3 because there is nothing stable for me to build on top of
... once I have something stable then I can reference it and update my modules.
... maybe serialization is stable enough so I could reference it but if stable and unstable things are in the same module I don't know what to do

<tcelik> I've updated http://wiki.csswg.org/spec/cssom with notes about what people have claimed are author demands. More evidence / statements welcome.

jdaggett: I think we need to have someone else co-edit to ensure we document implementation reality

<fantasai> glazou: John is proposing to have a document reflecting current implementations

<fantasai> glazou: I'm not sure that the current implementations are so inconsistent that this is undoable

<fantasai> glazou: Getting a stable spec, that only consists of the stable specs, I don't know that that's useful

<fantasai> Florian: If you ask me what the stable parts are, I have no idea.

<fantasai> jdaggett: I think there is value here. If you have a spec that focuses the set of features that have impelemtnations, even if they are inconsistent,

<fantasai> jdaggett: Trying to iron out those variations, that's value. Even if it's not sexy, it's still value.

<fantasai> jdaggett: I don't know that it has to be another spec, but we need to get the existing CSSOM spec ...

<fantasai> glazou: I think what you want is a better use of our time to add warning notes to the current DOM Level 2 spec than what you're proposing

<fantasai> arronei: This is what our test suites do

<fantasai> Tantek: I'm going to object John's assertion that we need another oc-editor, the editor's draft was lately updated

<fantasai> jdaggett: Editing the draft doesn't ensure it's moving towards something stable

<fantasai> Tantek: Let's work cooperatively within existing mechanism

<fantasai> Tantek: Oftentimes when another editor is needed for something, it's not due..

<fantasai> Florian: Anne is not interested in documenting the existing bits,, he 

<glazou> test

tantek: writing down what works today, I just want to establish how. can we write it down on the wiki page ?
... i just want to capture the request that we want to know what implementations do

<fantasai> sylvaing: Anne is definitely the right guy for the values API, but he's not interested in doing the documenting existing stuff

<fantasai> sylvaing: Putting things on a wiki page doesn't make them happen

<fantasai> szilles: you can't tell whether they'll happen until you put them there

<fantasai> <br duration=5m>

<fantasai> </br>

IDPF Joint WG meeting

<fantasai> +Brady Duga

<fantasai> +Bill McCoy

<fantasai> +Peter Sorotkin

<fantasai> duga: The Advanced Layout group of IPDF is going to begin work shortly

<fantasai> duga: our members have been clamoring for more powerful design, adaptive design, for page layout

<fantasai> duga: Right now when people want to do high design, they go back to JPEG, abspos, things that don't work well for multiple-size devices

<fantasai> duga: A proposal was made by adobe in PEU3 for more adaptive layout

<fantasai> duga: Didn't make it into 3, but portions of it turned into CSS Regions and Exclusions

<fantasai> duga: There's still a whole bunch of things not in those specs

<fantasai> duga: There's still a lot of clamoring for advanced adaptive layout features in a very short timeframe

<fantasai> jdaggett: There's a bi disconnect that I see between the way EPUB makes their specifications and the work that actually needs to get done.

<fantasai> jdaggett: If you define a schedule and then try to match features to that schedule, anyone in software will tell you that that doesn't work

<fantasai> jdaggett: Especially where complexity is involved

<fantasai> jdaggett: And when you talk about compelx layouts in CSS, that's by def complex

<fantasai> bill: The reason we're here is to make sure whe ahve a connection

<fantasai> jdaggett: A schedule-driven process will not get you something that will be interoperable.

<fantasai> jdaggett: The way EPUB has operated i nthe past is on-schedule. Whatever you're delivering is built on quicksand

<Bert> IDPF Advanced Adaptive Layout working group charter

<fantasai> jdaggett: You're referencing working drafts of this WG, and those chang.e

<fantasai> jdaggett: Rather than talk about scheduling, it's much more important to look at for the work of this group, where are the problems that are holding up things. And contribute from that angle. Rather than ctalking about scheduling

<fantasai> jdaggett: I think basically proposals are here. Would be more helpful if members at EPUB were focusing on what is needed to work out the problems associated with the various feature sthat re being proposed.

<fantasai> jdaggett: I see this a lot in vertical text layou. EPUB comes with a eature list, but when you have to figure out how these thigns actually work, participation is lacking.

<fantasai> bill: We ant to make sure participation is there and we contribute to broad open web andd assume open web wants to evolve to handle needs of publishing

<fantasai> bill: Over time we're getting closer and closer.

<fantasai> bill: EPUB2 referenced subset of CSS

<fantasai> bill: EPUB3 took a different approach. We followed the recommendation from the liaison to prefix things, etc.

<fantasai> jdaggett: We also had ppl form this group of not referencing WDs

<fantasai> jdaggett: Do what you want, but this will not get you interop

<fantasai> bill: The market demands were movin on anyway

<fantasai> dbaron: One thing you mentioned was seeking eventual alignment with web technology.

<fantasai> dbaron: One of the dangers there if you take a snapshot of a WD is that either one of two things will happen

<fantasai> dbaron: one is that the set of implementations doing EPUB will be different from Web technology, or same implementations plus flags

<fantasai> dbaron: And you'll end up with converging implementations within EPUB and converging implementations within the Web, and those two groups diverging

<fantasai> dbaron: The other possibility is that you'll have common implementations, and one or the other set of specs will end up bein ignored in reality

<fantasai> szilles: I completely agree with points by john and david, but we are sort of faced with 2 orgs trying to find an effective mechanism for cooperating. They have different constraints.

<fantasai> szilles: The warnings you express are valid

<fantasai> szilles: But more productive than trying to change how they're operating, is trying to minimize these kinds of issues or find ways for efffective coperation.

<fantasai> szilles: In particular one of these seems to be for EPUB to prioritize the feature list, so if we can only tackle some of it we know what to tackle fro myour side

<fantasai> glazou: Since I'm myself writing an EPUB2/3 editor, taken a look at all the editors , tools, renderers.

<fantasai> glazou: Most of them are based on web engines

<fantasai> glazou: The Web industry and EBOOK industry share the app layer

<fantasai> glazou: I don't think they are ogoing to be two different layers of runtimes

<fantasai> glazou: one for web and one for ebook

<fantasai> bill: We took decision in EPUB3 on buying that assumption

<fantasai> bill: Could have moved towards more DocBOok like vocab. Instead reference HTML5/CSS all-in

<fantasai> bill: Taking hoewver the reality that some of those won't be fully baked

<fantasai> bill: Decision was popular with vendors, lead to thinks like Apple iBooks based on WebKit

<fantasai> bill: Downside is that widely adopted modules that are WD

<fantasai> bill: CSS2.1 is baseline, but 9 modules referenced by EPUB3

<fantasai> bill: But all of those have some implementation

<fantasai> bill: We would like guidance from CSSWG.

<fantasai> bill: We are not W3C.

<fantasai> bill: As soon as there's cross-browser implementation, we're using those features

<fantasai> bill: We're here today because we ant to develop an optional add-on module to EPUB.

<fantasai> jdaggett: I'm telling you that within this group we've had ppl say "we have to do this this way because impl for EPUB already do this this way"

<fantasai> jdaggett: That's not the right way.

<fantasai> jdaggett: If it's something that's funamentally wrong, I don't buy that argument.

<fantasai> bill: We took the decision, knowing that our maintenance strategy for unfinished specs, would be to rev EPUB .1 .2

<fantasai> jdaggett: Go back to what brady said, Adaptive layout is a minefield.

<fantasai> jdaggett: It's very complex, it's hard to get right. if you start snapshotting, you will run into trouble.

<fantasai> glazou: You said cross-browser implementations, you'll add to EPUB

<fantasai> glazou: It's not beacuse we have cross-browser implementation of something at some point that the spec is stable

<fantasai> glazou: for us the only moment we can say something is stable enough is when we move from CR to PR.

<fantasai> glazou: The good example is gradients.

<fantasai> glazou: We have four incompatible specs for gradients.

<fantasai> glazou: At some point we may have 2 or 3 compatible implementation

<fantasai> glazou: If you rely on temporary stuff, if it's not a recommendation

<fantasai> Florian: I think Steve is a valid point. If we have a scehdule, a feature set, and a quality requirement

<fantasai> Florain: i.e. spec is advanced enough

<fantasai> Florian: We can't have these things all at the same time

<fantasai> Florian: Prioritizing your features is important.

<fantasai> Florian: We can try to push ahead faster with higher priority things.

<fantasai> Florian: We have a lot of things, some of which you care, some not so much.

<fantasai> Florian: We won't exclusively work on your things, but we can give it more wieght

<fantasai> Florian: We are quality-driven, you are schedule driven. The only way to work together is prioritizing

<fantasai> smfr: the othe rissue of snapshotting WDs is that it puts a burden on implementers

<fantasai> smfr: We have to maintain old behavior for compatibility, that we really don't want to have to maintain

<fantasai> smfr: In Ebkit we try to avoid flags, "we are rendering epub"

<fantasai> smfr: We might not even be aware that EPUB snapshotted some draft spec

<myakura> s/Ebkit/WebKit/

<fantasai> Markus: I totally understand where you guys are coming from. Because if you don't push the needle, you wind up with ... Amazon

<fantasai> Markus: I think he solution to this problem is prioritization Florian brought up. So if you keep separation of content and style

<fantasai> Markus: We of course don't work on content

<fantasai> Markus: That is best model to work forward

<fantasai> szilles: In category of requirements, might be useful to look at what Peter proposed to IDPF as kinds of things publishers are looking for

<fantasai> duga: Charter does list some priorities, and I epxect next few days we'll see more concrete proposal

<fantasai> duga: We're defining these as a vendor extesion, but will show what we might depend on.

<fantasai> duga: You might not do adpative layout on our schedule, but o we depend on calc(), or CSS regions,

<fantasai> s/duga/bill/

<fantasai> bill: We need to work together with those.

<fantasai> szilles: We've had demos from MS and Opera of paginated documents, so they're very much on the structure.

<fantasai> (using CSS)

<fantasai> szilles: They are going in that particular direction, so showing the PGT sort of things is relevant. It's written on top of HTML and CSS

<fantasai> hober: I tihkn echoing florian and john...

<mmielke> Correction: Amazon is having a model that is based on REC specs (CSS2.1 capabilites) and do not rely on specs in working drafts

<fantasai> hober: I think there's a diff between source of dependence of WDs in EPUB3 and this new high-design module whatever

<fantasai> hober: It's one thing to epub-prefix writing modes

<fantasai> hober: But this last couple days, I've seen some very interesting and very different proposals for doing these kinds fo layouts

<fantasai> hober: so different that even if we make an amazing amount of progres sin the next 6months, I have no idea what it's going to look like

<fantasai> hober: Baking in something like regions is petrifying.

<jdaggett_> fantasai: our specs have different phases

<jdaggett_> fantasai: you really don't want to depend on something that's not in the stabilizing phase

<jdaggett_> fantasai: all the layout proposals are in the completely unstable phase

<fantasai> bill: If you say we shouldn't reference something, then we won't.

<fantasai> bill: We want to have publishers avoid creating proprietary features

<fantasai> howcome: I agree with steve there is strong interested in moving to on-screen pages, so we have common interests

<fantasai> howcome: My concern with some of these e.g. regions is that they are quite complex and they will take a long time to stabilize

<fantasai> howcome: My demo shows that we can do 90% without adding a single property in CSS

<fantasai> bill: The pages things in Opera is awesome. I was showing it at a conference just recently.

<fantasai> bill: However, that's not what makes EPUB tick. The EPUB content isn't content that paginates.

<fantasai> bill: It's ... orchestrated

<fantasai> manifest

<fantasai> bill: I welcome paged views, but it's not what EPUB has

<fantasai> bill: That's EPUB2 level. We have picturebooks, magazines, etc.

<fantasai> bill: template-based stuff

<duga> AAL charter: http://code.google.com/p/epub-revision/wiki/AdvancedAdaptiveLayoutCharter

<fantasai> alex: I might be a little confused with teh background, what you're saying "us", is this EPUB or is this advanced adaptive layout charter group

<fantasai> bill: My immediate agenda item is coordination around advanced layout, but first issues raised are about genera principles of IDPF

<fantasai> standardization practice

<fantasai> bill: IDPF is a trade associate of publishers and ppl working in publishing. Very focused on publications, with a range from trade books to more compelx pbulications

<fantasai> alex: ... how much youre' going there.

<fantasai> alex Around 10 years ago, MS had an epub format which was subset of HTML+CSS

<fantasai> alex: It seems that in advanced layout is that you're willing to very divergent standizing of something

<fantasai> alex: is this something we should do in tihs group?

<fantasai> bill; that would be fantastic

<fantasai> bill: We asked W3C staff for review of our charter

<fantasai> bill: We're trying to meet the timeline of our members

<fantasai> bill: We are a date-driven organization, not so much quality

<dbaron> bill: we didn't receive comments on the charter from CSSWG members

<fantasai> bill: ... We're trying to get things out the door, and will accept the risks of some things fail.

<fantasai> bill: more like a startup

<fantasai> alex: You can have 8-month completely standard for a paginated document book and magazine layout and it will be ready for publication and have implementations? *skeptical*

<fantasai> bill: yes. were' generalizing work that a member has already done

<fantasai> peter: I'm from adobe, I'm member of IDPF WG.

<dbaron> peter == Peter Sorotokin

<fantasai> peters: We have a lot of idfferences, not only how the standards is driven, but also how these documeents actually live

<fantasai> peters: Complex websites get updated daily. Books don't

<fantasai> peters: The JS on the Web, you can't afford for books on the web.

<fantasai> peters: You want to publish it and forget about it, not maintain it.

<fantasai> peters: Puts a lot of pressure for having declartive ways of doing things.

<fantasai> peters: pressure is very differernt

<fantasai> peters: I was voicing a lot of similar concerns about referencing CSS WDs in IDPF

<fantasai> peters: A lot of these references come from East Asian market

<fantasai> peters: There are competing standards there. If we give up and not do it for 2 years, it's saying we won't do EBooks with CSS.

<fantasai> peters: You're lucky, there is no CSSX, nobody is trying to fork it or do someting completely different.

<fantasai> peters: We have this problem in ebooks, we cannot ignore

<fantasai> peters: One of our considerations for advanced layout proposal is to make sure it can be implemented today on top of existing browsers

<fantasai> peters: As long as we can do it today, we can be sure we can do it in future borwsers.

<fantasai> peters: That simpliefies the javascript.

<fantasai> peters: You'd need to augment your presentation with JS

<fantasai> peters: There is no requirement for JS in the publishing world as in browser

<fantasai> peters: iT's possible to move forward with moving creating more properties and eatures without touching the browser at all

<Zakim> Bert, you wanted to ask about ways to do liaisons

<fantasai> Bert: My conclusion so far is that we can only influence each others time scales so much, so how do we limit the damange?

<fantasai> Bert: two wasy to do that

<fantasai> Bert: One is to have timely info from EPUB of what they mean, so we can within the littel flexiblity we have, to work on their things faster

<fantasai> Bert: Also would be a good thing if we can give advice regularly to EPUB to avoid that they make too many mistakes

<fantasai> Bert: Steer you into somehting that's a littel bit safe. How do we make sure that happen?

<fantasai> Bert: Way to do that is liaisons, need people on both sides to communicate

<fantasai> Bert: maybe I should take some responsibility for that, it's in scope for my work anyway.

<fantasai> Bert: Maybe bring other people along to join meetings/telecons

<fantasai> Bert: Talking to each other is best way

<fantasai> Bert: Peter siad books cannot be changed. That means you need even more stable standards than the web browsers.

<fantasai> Bert: So you really need things that are extremely stable

<fantasai> Bert: You want to buy a book and 10 years still read it

<fantasai> bill: We had a lot of help from fantasai for EPUB3, but she was clear that she couldn't represent full bandwith of CSSWG

<fantasai> bill: I thin future of publishing in digital world is up for grab, some overlap with widgets and webapps

<fantasai> bill: various points of synergy

<fantasai> peterl: I in process of joining the EPUB group. I think you'll have interst in CSSWG to work with you guys. There would be good to have ppl from EPUB to join us on a regular basis

<fantasai> jdaggett: To your point about schedule and having things that you need to ship immediately.

<fantasai> jdaggett: that's ifne.

<fantasai> jdaggett: In the case of adaptive layout, you need to communicate to ppl in your organization, that by standardizing on your time scale, you pretty much guarantee incompat with future web standards

<fantasai> peters: The point we're trying to achieve, you can develop an EPUB UA on to p of the browser using JavaScript

<fantasai> jdaggett: Whether that's possible, I cannot tell you

<fantasai> jdaggett: It's not standardized

<fantasai> Florian: Sometimes specs are more stable and not marked at such. In this case we're alking about stuff that's really really unstable

<fantasai> hober: What bill said earlier, that EPUB is trying to be very agile organization. THink it's a very great term, want to hit on the vialbe part

<fantasai> hober: Like Florian said, if you have [3 things], there's inherent ension there.

<JohnJansen> s/ension/tension

<fantasai> hober: To resolve you're best off dropping features

<fantasai> ...

<fantasai> bill: We're clear on that, but our main focus of where compat is

<fantasai> bill: We want that markup produced by tool like InDesign will work in the future

<fantasai> bill: More important than compat with Web

<fantasai> s/future/future epub readers/

<Zakim> szilles, you wanted to show example document

<fantasai> szilles: Let me try to say what peters was saying in slightly different words.

<fantasai> szilles: there is a presumption in a number of the comments that the features that go into EPUB3+ are features that need to go into CSS

<fantasai> szilles: What peter is saying is slightly different. Pter is saying that CSS today provides enough capbility with JS to take a declarative language and present what you see on the screen

<tcelik> I'm a little confused about the confusion around communicating stability of CSS specs, isn't that what Beijing did/does (2007, 2010) ?

<fantasai> szilles: Adobe has been trying to pieces of that mechanism that are hard to replicate in JS and migrate them into CSS

<fantasai> szilles: on a timescale that fits with CSS. Because there are solutions that work in the interim

<fantasai> szilles: Regions would make these demos easier to do.

<fantasai> alan: But these demos don't depend on any of the new stuff

<fantasai> szilles: There are other things like line grid that can't be done in JS, and we'd need to move within CSSWG

<fantasai> szilles: So agreeing on those pieces is the most important thing we can do

<fantasai> Florian: What you said is imporant to me. Your highest priority is not necessary what should be our priority, since you can do much of this without us.

<fantasai> bill: ...

<fantasai> bill: From my pov, even if something's implementable in JS, if we nevertheless use a similar markup... or create our own, it could be a problem later

<Zakim> dbaron, you wanted to ask about future epub versions

<fantasai> bill: Don't want to sweep that under the table and say we're not worrying about it.

<fantasai> dbaron: You've mentioned that when you did EPUB3 it was essentially a different format from EPUB2. Is it backwards compatible?

<fantasai> bill: You could write EPUB3 that works on EPUB2 reader. Also EPUB2 books must work in EPUB3 reader

<fantasai> dbaron: What if EPUB3 depends on a technology that goes in a different way than this CSSWG goes?

<fantasai> dbaron: Would future versions of EPUB require the divergent technology? What CSSWG creates? Both?

<fantasai> duga: In EPUB3 we tried to point out pieces where things are likely to change incompatibly.

<fantasai> duga: We've committed to advancing with CSS, and pointing out to authors to beware of these potential changes

<fantasai> bill: EPUB4 might say a ruby property is deprecated and nonconformant in content, but UAs must still implement it

<fantasai> Alex: Some questions

<fantasai> Alex: I'm really surprised we're talking about liaisons and you doing some significant amount of work, but also we're doing here

<fantasai> Alex: I'm surprised that *I'm* not involved, as someone making major progress on Regions

<fantasai> Alex: why not talk to us?

<fantasai> jdaggett: alex editors regions

<fantasai> alex: Whatever.. finish regions sooner, there are opportunities for us to make parallel progress

<fantasai> alex: We here need help as well. kindof depressing that I discuss stuff with Vincent and nobody else contributes

<fantasai> bill: regions is 25% of advanced adaptive layout

<fantasai> Florian: Reigons is a good example. Because it's one of the difficult pieces here, only a few people understand it rest are waiting until they're done

<tcelik> what's the other 75%?

<fantasai> Florian: I fppl in your group are working on the same thing, participating here will make these ppl feel a lot less lonely

<fantasai> alex: My second point is, it seems that something that will get produced in a very short time and targetted at a very specific applications, seems very similar to a company shipping product with publicly document format, designed by one company

<fantasai> alex: we've done this with MS office format. develpped by one company for its purposes

<fantasai> alex: Seems similar to me.

<fantasai> alex: I fyou don't have any requirements for that format to be tied to CSS WG, does it belong to W3C?

<stearns> tcelik: see the charter that was linked above

<fantasai> alex: Would it be your format that is documented and supported by reader applications, and whatever CSS or HTML requires has ...

<tcelik> stearns thanks

<fantasai> alex: ... support forever

<fantasai> glazou: I have quesiton of prefixed properties you're going to use

<fantasai> glazou: Say you'll sync with us and drop things not used anymore

<fantasai> glazou: What if you adopt, e.g. gradients now.

<fantasai> glazou: Gradients are going to drasticaly change in next 12 months, at which point your gradients are entirely incompatible

<fantasai> glazou: It's not about dropping version, but changing the value of that property

<fantasai> glazou: The books in the old eversion would be incompat with new one

<fantasai> bill: Alias would be maintianed

<fantasai> bill: One option, reader detects 3.0 vs 3.1 and ...

<fantasai> peters: We would wait until you reached CR, even if we have our epub gradient

<fantasai> peters: Once you reach CR, we would import your stuff and be done iwth it

<fantasai> glazou: It's unlikely between editing tools for EPUB would be different than Web

<fantasai> glazou: You chose HTML+CSS

<fantasai> glazou: Again the rendering engines are going to be the same

<fantasai> glazou: so having -epub-prefixed properties does not make sense

<fantasai> glazou: Editing tools won't deal with that

<fantasai> glazou: You are not doing editing tool, you're doing a converter

<fantasai> bill: we agree with premise of minimizing prefixed properties

<tcelik> stearns, captured on the CSSWG wiki: http://wiki.csswg.org/spec#idpf-epub

<fantasai> bill: Only 3: text, speech, and ruby are used prefixed

<fantasai> bill: And those are generally for east asian typography

<fantasai> bill: we would prefer not to have prefixed properties, no question

<fantasai> bill: We want EPUB ot be portable documents base don open web

<fantasai> szilles: Actionable items I heard were to increase liaison participation in both groups

<fantasai> szilles: Bert volunteered to get involved in IDPF. Can we ask IDPF group to expand liaison with our organization?

<fantasai> glazou: We have a lot of things to discuss together.

<fantasai> bill: A mechanistic point, several of the key IPDF members have presence in CSSWG

<fantasai> bill: Adobe, Google, Apple

<tcelik> Can we ask IDPF to directly participate in CSS spec discussions on www-style?

<tcelik> s/ask/invite

<fantasai> bill: Might ask for redundant representation, but not up to us

<fantasai> glazou: We need coordination between two groups. Not the same thing as coordination between members.

<fantasai> szilles: Getting more participation from ppl not reprsented at the table today, more likely to have informative opinions and users

<fantasai> szilles: We have a lot of technologists at the table, far less users.

<fantasai> szilles: Unerstanding what's being asked for is a difficulty

<fantasai> <br>

<TabAtkins_> scribenick: TabAtkins_

florian: Extra agenda item - CSS3 Text, talking about text-transform

sylvaing: Extra agenda item - discuss how to move some of the current specs with lots of impl xp.

<bradk> xp = experience points?

JohnJansen: I'm thinking there are N new tests, and I'm wondering when they're going to be moved into a snapshot.
... And what it means if we don't have two impls passing those new tests.

fantasai: To the 2nd q, it doesn't mean anything - we're just moving to better interop. It doesn't revoke our Rec status.
... To the 1st q, I think somebody needs to make sure everything's in order and nothing's been lost (general vetting), and then we can just create a new snapshot any time.

JohnJansen: Should we have a regular schedule for that, so I can predictably work on it? Otherwise things tend to sit.

fantasai: Sounds good. What schedule do you want?

JohnJansen: I think it should be in conjunction with publishing errata, so tests over the new errata show up at the same time.

plinss: I think that makes a lot of sense, it's a no-brainer.
... Gerard's been reviewing a bunch of tests, and have a bunch flagged now with problems, but no one's working on them.

JohnJansen: I think one of the challenges is prioritization.
... Gerard is making a lot of comments (others too) - some are corrections, some are improvements.
... But they get the same prioritization. I'd like to prioritize a correction versus an optional improvement.
... We should jump on errors.
... When I come into work in the morning, though, I dunno if I should work on 2.1 tests or css3 new tests.
... We've got a lot of specs approaching CR or even Rec that need tests.
... But I've got a finite amount of time in my day.
... So some help in prioritizing would be helpful.

fantasai: You also wanted a snapshot at the time of errata pub.
... I'm not sure how long it takes to go from PER to Rec, but we are *way* behind on tracking 2.1 issues.

JohnJansen: Right. It's never on the agenda.

fantasai: And simple, I stopped tracking them - I switched to other specs. I was never even an editor, but I was doing most of the tracking.
... So we need somebody to track the issues for 2.1. They need to start now, track into the future, and move backwards to the LC deadline, which is a lot of stuff.
... And once we have a list, we can do a few issues each telcon and make progress.
... And make sure that resolutions end up in the errata and the draft.
... And I am *not* volunteering to do that.
... We can't have a new errata until someone takes it up.

<fantasai> http://www.w3.org/Style/css2-updates/REC-CSS2-20110607-errata.html

JohnJansen: yesterday we made a decision on margin-collapsing that needs to go in, for example, and it should be tracked.

fantasai: Theoretically it should be in bugzilla.

Bert: I've been lax about this, but I'm going to go through and extract things to Bugzilla.
... I'll start when I get back to my office.

<dbaron> http://wiki.csswg.org/spec/css2.1 says "Last mailing list sweep 2011-01-07 – arronei "

fantasai: If you can maintain a date range that you have definitely covered, that would be very useful.
... So if somebody decides to help you, they can just start at the last date you've touched and work backwards.

dbaron: I'll edit the 2.1 issues wiki to say that new issues go to Bugzilla.
... But we can still keep the mailing list sweep dates here in the wiki.
... And there's a bunch of open issues here in the wiki that need to migrate.

JohnJansen: Last idea - encourage the focus to fall on CSS3 modules, from a testing perspective, rather than continuing to focus exclusively on 2.1.

fantasai: One thing to keep in mind is that all tests in 2.1 are a subset of the tests we'll need in css3.
... So for B&B3, we'll just take all the relevant tests from 2.1, convert to reftest if possible, and then augment with new tests.
... Because that's easier than just writing entirely new tests.

plinss: In most cases, that's nothing more than adding a new spec link to the existing test. No moving, no copying, just add a new link and Shepherd will pick it up and track.

<gsnedders> How does Shepherd cope with tests becoming reftests?

JohnJansen: Even if we moved all the 2.1 tests for B&B to B&B tests, we're still not complete.

<plinss> not an issue, it just adds the reference

JohnJansen: So should we prioritize writing more css3 tests, or continue prioritizing 2.1.

fantasai: We need both, but we should prioritize writing new tests for 3.
... If people outside the WG want to work on 2.1, we should support them, though.

JohnJansen: Agreed, but I'm not sure that we should *encourage* them to work on 2.1.
... As a WG, we should give guidance to people who want to participate, and we should guide them to work on 3.

dbaron: Two types of tests - one is to validate the spec, and one is to improve interop.
... For the former, the priority should be writing for css3. For the latter...
... I don't want to discourage 2.1 tests. We're still undertesting parts of the spec.

TabAtkins_: So if someone comes up and says "I want to work on tests", we should encourage specific css3 tests.
... But if they want to work on 2.1 tests specifically, that's cool.

fantasai: We should have a list of specs that need testing help, but Gerard, for example, really wants to work on 2.1 interop, and that's fine.
... We can put a list on the wiki of specs that are in maintenance and could use tests.

JohnJansen: And additionally, we don't know and can't really track what parts of 2.1 need tests, we just have sort of a gut feeling.
... We can provide rough guidance there too, though.
... My preferred idea is that we're just done with 2.1, it's Rec, and we have a regular maintenance schedule, but it's not a living spec that needs active attention.

arronei: We need a per-spec maintenance schedule.

plinss: Probably in conjunction with the snapshot.

fantasai: We don't have anything new to snapshot yet, but we have a lot of things to errata.
... I don't see anything being added to the 2010 snapshot that's not already in the 2011 snapshot.

arronei: Why not put errata in there?

plinss: We can have a list of "these specs are in Rec, here's their errata", etc.

fantasai: Right now we just list the stable things and link to the spec. So that's no change.

arronei: I think it's good to publish an annual snapshot anyway. I want to see the 2011 snapshot, not the 2010 snapshot.

TabAtkins_: It's difficult to tell the difference between "there was no change, so no updates" and "the spec is dead, and it's out-of-date".

JohnJansen: And without a deadline to the issue tracking, work will grow to fill the alloted time.
... With a specific once-per-year date or something, we know when things are expected and have a push to get the necessary things done.

arronei: I'm hearing that we want a maintenance schedule. Should we set one up for 2.1 right now?
... And beyond that, each spec can have its own schedule (or hook into the existing one, we can evaluate per module).
... But we should at least nail down 2.1's schedule.

fantasai: PLH suggested republishing every year.
... Should we set a goal to have all issues in the tracker by the Feb meeting? Bert, is that workable?

Bert: Yes.

RESOLUTION: Have all 2.1 issues filed in bugzilla by the february meeting.

dbaron: I think 2.1 issues are best addressed on the mailing list, not in a f2f.

fantasai: Right, this is just a deadline for getting them in a tracker, not resolving them.

<dbaron> dbaron: We should at least attempt to deal with them on the mailing list before bringing them to a f2f meeting.

RESOLUTION: Publish an updated version of 2.1 and its testsuite annually.

RESOLUTION: Update the site/wiki/etc to publicly prioritize testing css3 modules rather than 2.1.

Bert: Once a year seems quite fast. More like every 5 years seems more reasonable.

plinss: We should keep the once-a-year as a review cycle. If it turns out that the issues are tiny, okay, we'll skip publishing this year.

PROPOSED EDITED RESOLUTION: Ensure that 2.1 is up-to-date yearly.

<gsnedders> IMO publishing once a year makes sense if there are non-editorial issues. Even if the issues are tiny it's probably still worth publishing if they have normative consequences.

plinss: Should we commit to publishing an annual snapshot?

RESOLUTION: Publish a snapshot annually.

fantasai: I think we should try to address 2.1 issues on the telcon each week.

plinss: Once we get some together, yeah.

dbaron: I think we should try to resolve them on the mailing list first.

plinss: Yes. But once a proposal appears on the mailling list, quickly discuss it for telcons.

JohnJansen: Another thing - I don't yet know how to prioritize the comments to the list for the current 2.1 testsuite.

fantasai: If it's invalid, fix it immediately.
... Tests that are imprecise (impls can pass when they actually fail the spec) should be fixed next.
... And then issues with metadata or reusability are nice-to-fix, but not strictly necessary.
... Every time we snapshot, the first two types should have all been fixed.
... The last should be fixed as time allows.

JohnJansen: I agree with that.
... I don't yet know when I should make sure that's done by.

fantasai: The last pub was June 2011, so the next will be June 2012, since we're doing yearly.

<fantasai> http://test.csswg.org/shepherd/

RESOLUTION: All issues with the tests (not the testsuite) go to Shepherd.

<fantasai> s/testsuite/infrastructure/

<dbaron> http://test.csswg.org/shepherd/

B&B issue

fantasai: Issue 189.

<fantasai> http://lists.w3.org/Archives/Public/www-style/2011Nov/0006.html

<fantasai> ISSUE-89

<fantasai> er ISSUE-189

<fantasai> http://www.w3.org/Style/CSS/Tracker/issues/189

<fantasai> http://lists.w3.org/Archives/Public/www-archive/2011Jul/0005.html

fantasai: Look at the pictures!
... Which of these 4 looks correct?

plinss: #4

fantasai: #1 is what IE implements.
... #2 seems to be hooking up the half-way points of the arc lengths.
... #3 is the current spec which is totally crazy.
... #4 is what I think is correct.

smfr: I think we should look at different border widths.

fantasai: I picked this for a specific reason.
... ...

smfr: Should border-radius influence what this corner-join should look like?
... In the absence, it's pretty obvious - you just go corner-to-corner.

<smfr> https://bug-9197-attachments.webkit.org/attachment.cgi?id=30423

smfr: This diagram shows our logical interpretation which is independent of border-radius.

dbaron: That doesn't work when one of the sides is very narrow or 0.
... You get a thick border that curves down, and then suddenly changes color at these two triangles, and that looks really bad.

<smfr> http://jsfiddle.net/jMb8k/

<fantasai> fantasai^: The reason I chose equal widths is that we know the angle must vary to zero when the width of either side is zero, and there are multiple ways to map the ratio of widths onto angles, but 1:1 is definitely 45deg.

<fantasai> fantasai^: The quesiton here is how do you interpret "45deg"

dbaron: Did you consider that the spec is mostly correct, but it should be looking at the curvature of the padding edge instead of border-edge?

fantasai: What if there's no curvature?
... The underlying algorithm is to find the point on the border curve where the tangent's angle equals the ratio of the border widths.

plinss: So find the angle that you would have without curvature, take the normal of that, then find the point on the outer curve with a matching tangent.

fantasai: That *sounds* right, but I'm not certain off the top of my head.

dbaron: Based on the fiddle, if we run the algorithm we're thinking of, it would produce the funny backwards-facing transition line that we don't want.

<tcelik> Frankly, I don't want to resolve this without a designer in the room.

fantasai: I *think* you take the ratio of the two widths and apply that to 90deg.

dbaron: Right, that's not our interpretation, and our intepretation is wrong.

<tcelik> If the goal is some sort of aesthetic ideal, we should base it on input from visual designer(s). Basing it on convenience of math or some approximate visual ideal is probably not a good way to resolve this.

<fantasai> tcelik: there's one on your left

plinss: I think it's take the line from the inner to outer corner, invert it over the 45deg line, then take the normal and match the tangent.

<tcelik> fantasai - and I observe that he's scratching his head.

dbaron: I think I agree with you on the outside point. I'm not certain that "closest point on the inside edge" is correct.

[some unminuted discussion about inner point]

<tcelik> ok I think we should issue a public call for proposals for how to resolve this issue (with the visual samples above as an initial set of possibilities, open to others), and then invite visual designers to provide input (on www-style)

<tcelik> I don't think we should spend further time trying to resolve this among this group in the f2f - I don't think is either a good use of our f2f time, nor will it result in a visually good solution.

I disagree, tcelik. This is productive so far.

<fantasai> plinss: You take the angle you'd have without a curve. Mirror it over 45deg (so a r45deg line won't change), then take the normal and find the tangent on the outer curve

<fantasai> plinss says to take the tangent on the inner curve

<fantasai> fantasai says she remembers trying that, and it gives bad results -- you want the shortest distance from the chosen outer point

dbaron: I believe a case something like "border-width: thick thin; border-radius: thin thick;" can produce bad transitions with this rule.

plinss: I think that has the right behavior. It's at least the limit behavior.

dbaron: Actually, this may not be a big deal either. [mutters over details]

ACTION fantasai to detail the algorithm, and produce mockups for lots of corner cases.

<trackbot> Created ACTION-396 - Detail the algorithm, and produce mockups for lots of corner cases. [on Elika Etemad - due 2011-11-08].

<dbaron> http://www.w3.org/Style/CSS/Tracker/actions/396

<florian> http://lists.w3.org/Archives/Public/www-style/2011Sep/0191.html

text-transform issue

florian: Look at point 4.

<dbaron> or, better, https://www.w3.org/Style/CSS/Tracker/actions/396 which is now "ACTION-396: Detail the algorithm options for position of color transitions on rounded borders, and produce mockups for lots of corner cases."

jdaggett_: The use-case for text-transform:full-size-kana is that in ruby, small kana is mapped to full kana, because otherwise they're too small to be readable.
... That's really the only use-case for this transform.
... And it's relatively small.
... I propose that instead of doing these small use-cases, we have an at-rule that lets you do arbitrary transformations.
... So authors can handle these themselves rather than having to come to us and get it included in a spec.
... I don't think this kana transform is unworthy, but it's a relatively small use-case.

florian: I think there are two main cases for a mechanism like this.
... First is the full-size-kana case. Well-defined and small.
... Another place where it's useful is removing accents from letters. We can't have a generic algo for this, because it depends on language and context.

<tcelik> to remove accents?

florian: But a specific author and specific document can do this.

fantasai: Dropping accents tends to be done *per word*. It can't even be done per documnet.
... In Farsi, diacritics usually arn't written, but some are preserved for readability.

florian: There are still useful cases where it's solveable.
... For cases that still aren't solveable, well, they're already not solved.
... Another case - old-fashioned long s may want to be transformed into a modern s. That's not something we'll probably ever care about as a group.

<fantasai> fantasai^: but in some words, they are preserved because otherwise the word would be ambiguous

jdaggett_: And in Japanese you coul dhave rules that shift from one form of kana to another form. Tiny use-cases.

<fantasai> fantasai^: you cannot solve this use case without a dictionary

jdaggett_: For i18n, it's simpler to just give people a rule. If we find people using a particular kind consistently, we can then standardize it.

howcome: I think this is a good idea, and is similar to @counter-style.

jdaggett_: I propose then that we drop this property value and move towards defining this transform rule and its syntax.

<tcelik> specifically: text-transform: uppercase turns "0.1µF" into "0.1MF"

szilles: One concern I always raise is, is this opening a security hole?

dbaron: It seems like anything you can do here, you can do with a font.

TabAtkins_: or in many cases, just ordinary javascript.

dbaron: As an aside, I'm not crazy about the specific syntax being proposed, but I won't get into that now.

stearns: I like this idea, but should the full-size-kana rule still be added, since it seems useful?

jdaggett_: Given that the use-case is only for Ruby in japanese, and only for people who want to keep their original content that comes with small kana, I don't think we need to.

szilles: A solution would be to use *this* transform as an example in the spec.

fantasai: The table is non-trivial.
... And the *idea* that you can ask the UA for this sort of thing is new and strange.
... If it's tricky and unintuitive, nobody will do it though.

jdaggett_: If there's an example, or a wiki article or something, it's a simple cut-and-paste to put it in your page.

howcome: Or an @import. That works for fonts already.

fantasai: They'll do that because it's shiny and new and cool.

howcome: We're not fighting the functionality, just the syntax. And making it available to other languages.
... For example, in typesetting my Ibsen book, he used a peculiar form of punctuation. I had to edit a font to do that.

plinss: I hear many in favor, and one strong objection.

[three strong objections]

Bert: I think this is creeping transformations to CSS.

jdaggett_: Do you support the keyword itself?

Bert: You said it was necessary, so yes.

<br type=lunch duration=1h>

<Bert> Scribe: Bert

Image Values

[fantasai draws on whiteboard]

fantasai: Can somebody project the gradient syntax definition?

<szilles> join #ac

<fantasai> http://wiki.csswg.org/ideas/radial-gradients

<fantasai> http://lists.w3.org/Archives/Public/www-style/2011Oct/0859.html

fantasai: Look at bottom of wiki page.
... Not clear what is going on in these examples.
... Some colors, som epercentages...
... So want all notations to be more obvious.
... Please look at the e-mail for some ideas.
... Not ncecessary to have positional arguments in CSS.

JohnD: Functional notation is usually interpreted as a function w/ params.
... This keyword notation is going away from that.

Tab: Bu you can see it as going back more to how CSS properties work.

JohnD: When I read a parentheseis, I expect a function.

[Some people offering opiions]

fantasai: Inside the func. notation it is pretty much like a value ntation.
... Not a function call, but a subset of the value.

PeterL: We have other things without commas.

Simon: But always commas in functions.

Molly: Most people are not computer scientists.
... What is intuitive.
... The original proposals were completely unitutive.
... I have no context from CS. Peopel like me just need words.
... Gradient "from" here "to" there.

JohnD: But look at AppleScript. It is frustrating.

Tab: But isn't this the case for every proeprty?

JohnD: It's different inside functional notaitons.

Markus: Should avoid functional notation in general.

Simon: How do you know [something]?

Molly: It's the words, as long as it is logical.

JohnD: Any kind of formal language needs to be consistent.
... In similar cases, you use similar notations.
... But this is mixing things together.
... Will lead to confusion.

Brad: I think it rather clarifies.
... This is not AppleScript.

fantasai: Looking at the exampels, I cankind of see what is going on.
... With the other ones, I have no idea.
... That's why I want to go here.
... Most functional notations we have so far, have commas in thesame way as in values without functional notations.

JohnD: Do we have func. notations with keywords anywhere?

Tab: We're adding that right now.
... Most functions sofar are pretty trivial.

JohnD: So this is the first time for keywords in functional notations.

<brianman> helps to have the right port - 6665

<dbaron> I think keywords inside functional notation are reasonable.

Simon: Slippery slope. But other way to think about it is name-value pairs.

Howcome: OK with changing. We can also drop the just the parentheses here.

<brianman> There was a lot in e-mail. What's the current proposal?

Howcome: Programmers have traditions.
... We can do differently, as a string or something.

PeterL: Cf Python and others.

<TabAtkins_> Like radial-gradient(center: 20% 20%, shape: cover ellipse, colors: blue, red, black)?

JohnD: But they are specific syntaxes.

PeterL: So is CSS.

<brianman> There's at least one problem with that syntax, Tab.

PeterL: The point is they are *not* parameters, because it is not a *function*.

<brianman> You probably want .... radial-gradient(center: 20% 20%, shape: cover ellipse, colors: |blue, red, black|) ... but something other than the pipe character.

<dbaron> this is starting to look more like Apple's original proposal

fantasai: I hear objections to commas, because that makes it different from C. I dont' hear that my eample is unreadable.

<brianman> Your syntax above isn't clear on what the commas separate. Are they separating colors or the next param pair?

JohnD: It's not C. It's consistency with other parts of CSS.

<brianman> Can you repeat your specific example, fantasai?

fantasai: We dont' use commas between values in CSS.

[For fantasai's idea, see e-mail linked earlier]

<brianman> [There are like 20 emails.]

<plinss> http://wiki.csswg.org/ideas/radial-gradients

<plinss> http://lists.w3.org/Archives/Public/www-style/2011Oct/0859.html

Rossen: fantasai's is not necessarily easier.
... Functional syntax is hiding three gradient properties. Why do need to be in the notation, not in proeprties?

<brianman> Are you referring to this flavor: radial-gradient(<shape> keyword <position> keyword <stops) ?

Tab: They are values, gradietns aren't properties.
... We don't add twenty-something properties for images.
... Can add @rule or point to SVG.
... But gradients are right at the edge, can still be in CSS, n a funtion.

sylvaing: At some poijt we switch to SVG, you say. Then we need to inline SVG.

ErikD: [missed]
... Doesn't seem natural to me.

Simon: Trabsforms has functional notations. But all numeric.

<bradk> rect() does not require commas: http://www.w3.org/TR/CSS2/visufx.html#value-def-shape

<dbaron> rect() is an accident from the examples and the normative prose in CSS 2.0 mismatching

<smfr> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html#FilterFunction

<brianman> Why is "radial-gradient(circle from center as red, blue)" better than "radial-gradient(circle from center, red, blue)"? In my opinion it's worse.

Tab: Filter functions shorthand in CSS looks like comma-separted now, but will change them to look more like CSS proeprty. Don't need th ecommas. Space is enough.

Simon: Then we need to do that for trnasforms too, Consistency.

<ed> s/Doesn't seem natural to me./the "from ... as" syntax doesn't seem natural to me./

Luke: Need More general syntax system than the English word thrown here and there.

fantasai: Shorthand and indivisual propeties if needed.

Simon: @-rule, like keyframe [...]
... Use JSON :-)

<glazou> I would like to avoid "silent" tokens

<glazou> i.e. like in genetics, genes that express nothing

<glazou> if we could keep meaningful stuff only

<glazou> please let's do that

<brianman> Clarify, glazou?

<glazou> in that light, from and as are meaningless

<brianman> Ah.

<glazou> they help readability by humans

<glazou> don't help the syntax

<brianman> I would agree on 'as' but 'from' has some value.

Shane: Pretty strong relation to JSON idea. name:value idea.

<glazou> and also complexity parsing

<brianman> It solves the size version position problem with lengths.

Florian: That's not what was proposed here.

<smfr> gradient(shape circle, from left, as red, green)

<brianman> Useless as in that version, smfr.

<smfr> gradient(shape circle from left as red, green)

Shane: Those "silent" tokens exist in JSON, too.
... Slight difference in tokens.

fantasai: Can vary order, although it looks weird with shape at the end.

<brianman> Sidenote: I think from is the wrong word. At is a better word.

JohnD: Maye be readable, but allows syntaxes that are gibberish.

<brianman> In light of offset focal point in the future.

PeterL: Gibberisgh is loaded term.

<fantasai> peterl: comma-separated numbers are gibberish to me if I'm not intimately familiar with the order of arguments

Shane: Is it better if it were order-independent and we say we can use it in other situations, too?

<brianman> It can't be completely order independent. The color stops.

JohnD: It's what an author expects.

<glazou> +1

Molly: Solve deoendence on order with education.

<glazou> won't work

Molly: And a question:
... What Simon just wrote is beutifule. What is the problem with it?

Simon: Complex grouping, precendence issues...

fantasai: Property values have this already.

<dbaron> The "shape" in what Simon wrote doesn't seem to me to add anything useful.

howcome: Need to start with "from" right?

<brianman> @dbaron it has value here: radial-gradient(size 25px 25px, from 25px 25px, red, green)

<brianman> s/value/usefulness/

Simon; CSS grammar doesn't restict what goes insoide (), does it?

Bert: Correct.

<rossen> bert: didn't have time to look at the proposed syntax, would like to come back and comment in a week

Florian: Should we allow ourselves the same flexibility inside () as for other values.

<dbaron> brianman, I was specifically referring to the "shape" rather than the other keywords

howcome: Not more restrictive, just using more keywords, with may be more or less intuitive.

fantasai: [missed]

<brianman> @dbaron - so you want "radial-gradient(circle...) and "radial-gradient(size 25px 25px, ...)" ... Meaning only a keyword in the size case?

Tab: CSS is designed for English speakers.

PeterL: No consensus?

<brianman> ... or are you saying that the from is clear enough that the other param doesn't need it?

<fantasai> fantasai^: gradients is a particularly tricky case because there are many arguments of the same type that need to be disambiguated

<TabAtkins_> A current example of using keywords in functional notation:

<TabAtkins_> file:///home/tabatkins/csswg/css3-lists/Overview.html#symbols-function

Molly: Seems less to do with keywords, more to do with notation, i.e., the brackets.
... That means something for computer scientists.

<TabAtkins_> http://dev.w3.org/csswg/css3-lists/#symbols-function

Molly: Simon's examples in IRC make sense to me.
... What is the pb with those?

<brianman> @Bert - Color stops problem.

Molly: Is it the notation? The limitations?

Simon: No consensus about needed the shape.
... We need to think about all the things that use func. notation.

<brianman> 1. The color stops are different from the shape/size/location params. 2. the color steps are a list.

<brianman> 2 - If you're trying to get order-variability support, you need to group the color stops

Florian: Values in general; some have just numbers, some have extra things to make it clearer. So far we didn't consider that inconstsient.

<brianman> 1 - I think of the color stops as a different thing than the params...just like for linear.

Florian: Why do we think it is incosistent here?

PeterL: Transforms use a matric, that is a tradition, makes sense to people, no need to label it.
... What now?

s/matic/matrix/

Tab: Want to add a focal point later to gradients.
... More general discussion about notations later.

<brianman> For those that didn't read the e-mail, with one slight adjustment I could accept Elika's radial syntax.

Tab: Let's settle on radial gradients now.

Brad: linear gradiesnt have spaces.
... Spaces separate items in a list.

<fantasai> Brad: Linear gradients already has "to", already uses spaces to separate certain items, and uses commas in a way that's consistent with how we use them in other property values

Brad: We are only putting () around them here.

Tab: Poll on gradients, and general notation discussion later.

<brianman> Isn't tha the same as yesterday, Tab?

Florian: Difficult to it in that order.

<brianman> (What's new in your poll.)

Tab: It slows down gradients. We know the features, we just discssu synatx forever.
... Tjis is a minor issue.

Shane: Let's get gradients out first.
... Schedule alternative syntaxes discussion.

fantasai: That's terrible. Have to learn two syntaxes.

<brianman> @molly - sorry, your syntax confuses me terribly

PeterL: Serialization issues too.

<brianman> ...the middle param

sylvaing: Who would formally object to [???]

<fantasai> s/[???]/the current comma-separated syntax/

<brianman> the 09/08 WD you mean?

<brianman> 2011/09/08

PeterL: Value in readability and extensibility.

<fantasai> plinss: A fair question would be to ask would anyone formally object to publishing with this syntax?

<fantasai> sylvaing: why should we change it?

[two many talking at the same time]

<fantasai> plinss: I think it's a win for readability and understandability, and a big win for extensibility

peterL: valuable to look at this and see if it blocks something later.

howcome: What is the example?

fantasai: Radial with offset center.

<dbaron> To be clear: I really don't like "shape circle", since "circle" is obviously a shape so "shape" is redundant -- unless we do something more explicitly property:value-like.

Tab: circle at offset X X

JohnD: At some point it gets easier to have an @-rule, as simon said.

howcome: I think gradietns is already beyond readabilty.

Tab; Why didn't you say that earlier?

s/;/:/

Tab: We settled on all this months ago.

JohnD: But you also say you want to extend this.

Tab: Yes, and at some point we say let's not extend any further.
... We can have that discussion in the future.
... But keep open possibility to extend in current syntax.

PeterL: I want gradients done. Don't publish and change again.
... Let;s strawpoll.

<fantasai> Tab^: That was in the WebKit syntax, and I dropped it partly because I couldn't get a syntax that was reasonable with it.

[preparing strawpoll, finding exampels to show on screen]

<JohnJansen> brianman, can you post what slight adjustment you need in order to accept Elika's syntax?

<brianman> sure

<TabAtkins_> Option A: radial-gradient(1em 2em, 3em 5em, red, orange, yellow)

<brianman> (i'll wait for tab)

<TabAtkins_> Option B: radial-gradient(3em 5em at 1em 2em as red, orange, yellow)

<TabAtkins_> Option c: radial-gradient(3em 5em at 1em 2em, red, orange, yellow)

<brianman> Yah, that about captures it

<bradk> B.2 radial-gradient(3em 5em at 1em 2em with red, orange, yellow)

<brianman> A=WD, I prefer A but I'm fine with C. I dislike B for at least two reasons.

Tab: Second is Elika's
... 3rd is a variant, with "," instead of as

Luke: Option missing is to name the first params.

Florian: Not sure this is the right set of options for the poll.
... Need to eliminate.

Tab: Can give multiple votes, to all the ones you like.

<shans> D. radial-gradient(shape 3em 5em at 1em 2em as red, orange, yellow)

<brianman> @cyril - correct on SVG, canvas

Bert: [question about ems in the notation]

JohnJ: A

howcome: Where is the "from" keyword that elika propsoed?

<brianman> good point

<fantasai> plinss: The word is unimportant, the concept is what we're voting on

PeterL: The exact word is not inmportant.

<dbaron> how does the ellipse/circle closest-side/closest-corner/farthest-side/farthest-corner fit into this?

<fantasai> part of <shape>

<TabAtkins_> dbaron: First argument is <shape>, which includes that.

PeterL B, then c then A

<brianman> replace "3em 5em" with the shape keyword

<brianman> in all the options

<brianman> the <shape> keywords rather

s/peterL/PeterL:/

howcom: a

koji: A

markus: a

Alan: b, c

soonbo: a

florian: b, c, a

<dbaron> (I saw that as both a shape and a size, but oh well...)

bert: abstain

masa: abstain

EricM: b

<bradk> Brad: C, then B

brad: c, b

<brianman> [After the poll I'd like to address dbaron's question.]

simon: a, d

alex: abstain

kimberley: abstain

rossen: a, c

<TabAtkins_> (Yes, "radial-gradient(ellipse at top left, red, blue)" is fine.)

sylvaing: a

johnD: a c

arron: b, a

tab: b, c

shane: b, c

kimberlyblessing: a

<glazou> abstain

fantasai: b, c

luke: a, d

<fantasai> plinss: If you group b+c as one camp and a as a second, it's a dead tie

PeterL: This isn't showing us anything.

<dbaron> my prefs are d with the b->c substitution, c, a, if I'm understanding correctly

fantasai: Open up to designers on wiki.

Tab: resolve in two weeks?

<brianman> Resolve how?

<fantasai> on csswg blog

<brianman> ah.

<scribe> ACTION: fantasai to make post with the options, just two options. [recorded in http://www.w3.org/2011/10/31-css-minutes.html#action08]

<trackbot> Created ACTION-397 - Make post with the options, just two options. [on Elika Etemad - due 2011-11-08].

<brianman> The "2" in that action is troubling.

<brianman> Either you choose to screw B or C.

[discussion about @-rule]

RESOLUTION: decide in two weeks.

<glazou> :)

[agenda discussion]

<plinss> 10 mins

<plinss> pf joint meeting at 3:30

Variables

<glazou> plinss: and variables ?

<glazou> ah ok

Tab: We talked about it in Seattle. I revised things since.

<JohnJansen> dbaron, we're going to power through a bit of variables first, then do the joint meeting. short break before joint meeting

Tab: Let's go over it.
... Variables were @-rules before.
... That has scoping problems, etc.
... So new idea is to define data-* properties.
... Can be any name after data-. Need to define the syntax exactly.
... Later.
... They have arbitrary name and arbitrary value.
... Attaches these proeprties to an element.
... Follows cascade, inheritance, exactly like every othe rproperty.

Markus: So always inherited?

Tab: Yes, always inherited.
... A data- property doens't do anything by itelf.
... But you can use them by referring to them.
... Example 1:
... Sets data-border-color on :root.
... Inherits to everything.
... An H1 later on has this property.
... Can refer to is: background: data(border-color)
... Example 2:

s/.. /.../

scribe: Easier to understand, at least when you understand cascade and inheritance. :-)
... Libraries can declare their own variables.
... With this system you just set it on the root, and won't interfere.

JohnD: name collision?

Tab: Still possible , but addresses the majority of them.

JohnD: So each of these data-* are in the cascade and visible to any element.

dbaron: Yes, all inherited.

JohnD: So if you set then inside a class...

Tab: Then nothing outside that class they are not there, that's inheritance.

dbaron: Some library that deals with a subtree.

Tab: Such as widgets.

dbaron: Tehre are other kinds of libraries.

johnd: You say it resolves na,me collisions, but it simplifes, eliminates global scopes.

PeterL: Not eliminated problem, bur reduced.

howcome: when do you know a value is invalid?

<glazou> so I think this is clearly the cleanest and best CSS-integrated variables proposal since 1998 ; it's easy to understand, easy to edit, fast and easy to deploy from a web site point of view ; love it

Tab: At computed value time.
... Say it recolves to color: foo
... At that point it is not a valid value, and the initial value will be used. Not the previous rule.

fantasai: memeroy usage?

Tab: Shane tried and said it was no so bad.

[break]

s/memeroy/memory/

<glazou> so no resolution here ?

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/shadow DOM/OM/
Succeeded: s/conpressed fonnt/a line consisting only of ideographic characters/
Succeeded: s/named regions/named pages/
Succeeded: s/elet/elements/
Succeeded: s/insect/inset/
Succeeded: s/impat/impact/
Succeeded: s/arronei/sylvain./
Succeeded: s/David/ for Animations module./
Succeeded: i/Present:/Scribe: Bert
FAILED: s/Sylvain and David/Sylvain and David for Animations module/
FAILED: s/netwok/network/
Succeeded: s/undertsnad/understand/g
FAILED: s/preceisley/precisely/
Succeeded: s/doens't/doesn't/g
FAILED: s/at hat point/at that point/
FAILED: s/perf./performance/
FAILED: s/Simpelr/Simpler/
FAILED: s/longe rin/longer in/
FAILED: s/feeback/feedback/
Succeeded: s/ppl/people/
FAILED: s/inifite/infinite/
FAILED: s/taht/that/
FAILED: s/or z-index <integer>/or z-index <number>/
FAILED: s/cass/cases/
FAILED: s/beyond/fully/
FAILED: s/tpib/tpilb/
FAILED: s/one/two/
FAILED: s/, or .../and isn't a non-replaced block/
FAILED: s/waned/wanted/
FAILED: s/and isn't a non-replaced block/, or something that doesn't go in a line box and isn't a non-replaced block/
FAILED: s/ert;/Bert:/
FAILED: s/TabAtkins_/fantasai/
FAILED: s/TabAtkins_:/fantasai:/
FAILED: s/fantasai/TabAtkins/
FAILED: s/'space' should be 'stretch'/'space' will mean whitespace in web author's mind, please use something else like stretch (just an example)/
FAILED: s/this/this module/
FAILED: s/florian/fantasai/
FAILED: s/Ebkit/WebKit/
FAILED: s/duga/bill/
FAILED: s/ension/tension/
FAILED: s/future/future epub readers/
FAILED: s/ask/invite/
FAILED: s/testsuite/infrastructure/
FAILED: s/Doesn't seem natural to me./the "from ... as" syntax doesn't seem natural to me./
FAILED: s/value/usefulness/
FAILED: s/matic/matrix/
FAILED: s/[???]/the current comma-separated syntax/
FAILED: s/;/:/
FAILED: s/peterL/PeterL:/
FAILED: s/.. /.../
FAILED: s/memeroy/memory/
Found Scribe: Bert
Inferring ScribeNick: Bert
Found ScribeNick: fantasai
Found ScribeNick: fantasai
Found ScribeNick: TabAtkins_
Found ScribeNick: sylvaing
Found ScribeNick: TabAtkins_
Found Scribe: Bert
Inferring ScribeNick: Bert
ScribeNicks: Bert, fantasai, TabAtkins_, sylvaing

WARNING: Replacing previous Present list. (Old list: Luke_McPherson_(Google), Shane_Stevens_(Google), Steve_Zilles_(Adobe), Molly_Holzschlag_(Invited_Expert), Mark_Silverman_(Adobe), Deepa_Subramanian_(Adobe), Bert_Bos_(W3C), Alan_Stearns_(Adobe), Arno_Gourdol_(Adobe), Brad_Kemper_(Invited_Expert), Tab_Atkins_(Google), Elika_Etemad_(Mozilla), Daniel_Glazman_(Disruptive_Innovations), Koji_Ishii_(Invited_Expert), John_Daggett_(Mozilla), David_Baron_(Mozilla), Arron_Eicholz_(Microsoft), Sylvain_Galineau_(Mi)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Luke_McPherson_(Google), Shane_Stevens_(Google), Steve_Zilles_(Adobe), Molly_Holzschlag_(Invited_Expert), Mark_Silverman_(Adobe), Deepa_Subramanian_(Adobe), Bert_Bos_(W3C), Alan_Stearns_(Adobe), Arno_Gourdol_(Adobe), Brad_Kemper_(Invited_Expert), Tab_Atkins_(Google), Elika_Etemad_(Mozilla), Daniel_Glazman_(Disruptive_Innovations), Koji_Ishii_(Invited_Expert), John_Daggett_(Mozilla), for_Animations_module._Baron_(Mozilla), Arron_Eicholz_(Microsoft)

Present: Luke_McPherson_(Google) Shane_Stevens_(Google) Steve_Zilles_(Adobe) Molly_Holzschlag_(Invited_Expert) Mark_Silverman_(Adobe) Deepa_Subramanian_(Adobe) Bert_Bos_(W3C) Alan_Stearns_(Adobe) Arno_Gourdol_(Adobe) Brad_Kemper_(Invited_Expert) Tab_Atkins_(Google) Elika_Etemad_(Mozilla) Daniel_Glazman_(Disruptive_Innovations) Koji_Ishii_(Invited_Expert) John_Daggett_(Mozilla) for_Animations_module._Baron_(Mozilla) Arron_Eicholz_(Microsoft) Sylvain_Galineau_(Microsoft) John_Jansen_(Microsoft) H�kon_Lie_(Opera) Peter_Linss_(HP) Chris_Lilley_(W3C) Vincent_Hardy_(Adobe) Rossen_Atanassov_(Microsoft)

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


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

Got date from IRC log name: 31 Oct 2011
Guessing minutes URL: http://www.w3.org/2011/10/31-css-minutes.html
People with action items: arron arronei bert fantasai jdaggett tab