W3C

- DRAFT -

SV_MEETING_TITLE

07 Feb 2012

See also: IRC log

Attendees

Present
Regrets
Chair
SV_MEETING_CHAIR
Scribe
fantasai

Contents


<glazou> test

<sylvaing> scribenick: sylvaing

howcome: I think we agreed we want to achieve modern magazine designs
... we disagree how to reach that goal
... I prefer a declarative approach
... others prefer a hybrid approach that involves script

steve: I thought we came out of the discussion thinking that we needed declarative as well as scripting

<successful re-enactment of yesterday's discussion>

tab: allowing the last region be auto-sized would help a lot
... being able to flow a region into a grid cell (which used to exist with ::slot) would also help
... with those two combined, a large number of these layouts would be possible

<TabAtkins_> ack

vincent: the first one is something we have as an issue.
... we also talked about making multicol a region; in particular make the last region a multicol
... we'd also like to make a proposal for page templating

rossen: our goal is to present a page template at the next f2f which would address basic region auto-generation needs
... so this would allow us to go back to the regions spec now and work on known issues

alexmog: I think we generally disagree on the order of implementation

howcome: my concern is that the first implementations coming out will force the creation of dummy divs through script

alexmog: we only aim to enable implementation in this space and gather feedback
... I'd like to discuss issues in the regions spec.

<tantek> the Microsoft implementation of regions is -ms- prefixed right?

tantek, yes

howcome: i think a page template spec is necessary
... regions and page templates should come together is necessary

<plinss> ack

vincent: I see it as a two step process. if we do allow regions to be multicol elements I think it mixes well with your solution
... this provides a progression that doesn't require scripting

tab: is there any reason why all regions couldn't be multicols?

vincent: no

alexmog: can we put region issues on the agenda?

howcome: sure, i just don't want to make a general decision on whethe this is the right way forward until we have visibility into your general model

vincent: as a way forward we'll submit a page template, add support for multicols and paged overflow
... at the f2f we can show something that's much more complete

florian: that way we'll be able to compare complete solutions based on use-cases

howcome: we should also look at Bert's use-cases
... we need a set of use-cases to evaluate the various proposals

jdaggett: I think it would also be useful to share presentation material like this on www-style in advance so as to gather feedback from a wider group

rossen: valid feedback, thank you

<scribe> ACTION: vhardy Draft a page template proposal for the May f2f [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action01]

<trackbot> Created ACTION-422 - Draft a page template proposal for the May f2f [on Vincent Hardy - due 2012-02-14].

Regions issues

<dbaron> vhardy: Should I put it on dev.w3.org?

Bert: region styling using @-rule is different from pseudo-element styling and creates inconsistencies

<dbaron> daniel: of course; we have things there that aren't even in the charter; I won't entertain objections to that

vincent: there was feedback at the last meeting on the way we presented issues and I wanted to start by showing how we dealt with that

vincent projects css3-regions ED

vincent: we're filing all the spec issues in Bugzilla
... before then we only had issue markers in the spec
... now all the issues in the spec link back to bugzilla, and the short description is shown in the margin
... this is done in a scripted manner and matches them with the spec and appends them a report at the end of the spec. it lets you know whether new issues are not marked in the spec. this helps editing.
... let me know how to make it more useful

<dbaron> I didn't follow what the buttons at the bottom were supposed to do.

<ChrisL> inline bug links in the spec are very useful

<ChrisL> tools better in a subdirectory instead of littering the root

<scribe> ACTION: vhardy Create a shared directory to post the bug helper script and document it on the wiki [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action02]

<trackbot> Created ACTION-423 - Create a shared directory to post the bug helper script and document it on the wiki [on Vincent Hardy - due 2012-02-14].

first bug was https://www.w3.org/Bugs/Public/show_bug.cgi?id=15159 to add use-cases

we've done that

http://wiki.csswg.org/spec/css3-regions/regions-use-cases

howcome: in addition to the CSS and HTML, it'd be useful to see any script that is needed to flow in more content
... do you encourage others to add more to the wiki page?

vincent: yes

<scribe> ACTION: vhardy make a generic use-case page linking to proposed markup solutions [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action03]

<trackbot> Created ACTION-424 - Make a generic use-case page linking to proposed markup solutions [on Vincent Hardy - due 2012-02-14].

RESOLVED bug 15159 is closed

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15733

vincent: this is about creating regions declaratively

howcome: let's close it once there is a proposal

vincent: this will be solved in the template proposal
... we'll update the bug to reference the pending action

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15131

vincent: originally the spec had a section on how regions integrated with different layout systems since regions don't create layout. this was taken out
... then we explained how a region could be selected or created but this was not to be covered in the spec
... but we were left with this example and we were asked to update it
... the goal should be to indicate there is an overflow area and that should be item 4 in Figure 1
... the point of the example is to show there is a catch-all area

<scribe> ACTION: vhardy Make item 4 a multicolumn overflow [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action04]

<trackbot> Created ACTION-425 - Make item 4 a multicolumn overflow [on Vincent Hardy - due 2012-02-14].

howcome: <creep-laugh type="evil">

vincent: Bug 15186 is about auto-generation and is to be revisited with future proposals. Same for 15187.

<Bert> (The example of 15131 doesn't really add a layout-based solution, does it? I still see empty HTML elements...)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15811

alexmog: we are not proposing to flow content from external resources at the moment
... providing flow from external resources could be out of scope, or the Regions spec shouldn't restrict the origin of a resource

ChrisL: I don't think it should be out of scope since the alternative would be to write script to pull in content

alexmog: out of scope may be the wrong term
... can regions assume that every element or node comes from the same origin?
... I think it's useful to assume it but it is limiting

dbaron: given the seamless iframes feature of HTLM5, I'm not sure how much this matters
... if you assume you have seamless iframes then you don't need features in CSS

<ChrisL> is there a benefit to assuming that all the nodes are in the same document?

<ChrisL> alex: yes, you can determine element order

alexmog: but we want to allow indirection into a different document without changing the style of this document
... seamless iframes does not have that option
... I have a options on the wiki but I am not yet ready to commit to any of them

http://wiki.csswg.org/spec/css3-regions#issue-24creating-a-named-flow-from-external-resource

<dbaron> TabAtkins: there are security concerns with integrating iframes and, e.g., determining the height of the contents, without using the mechanisms in seamless iframes

<vhardy_> http://wiki.csswg.org/spec/css3-regions#issue-24creating-a-named-flow-from-external-resource

alexmog: one option involves using an iframe element; another uses a separate property; a third uses a flow rule. we can discuss these but work remains to evaluate the solutions as well as understand seamless iframes

tabatkins: this should be discussed on www-style as there are issues with it

alexmog: the Regions spec should note that the content of a named flow may come from another document

vincent: should we retitle the bug?

<glazou> break time at 10:45am

vincent: we can note in the spec that the current version assumes the content comes from the same document pointing to an issue to resolve it later

<glazou> TabAtkins_: selectors 4 after the break ?

<TabAtkins_> glazou: I'm okay with that. Check with fantasai, since I think it's generally her topic.

Bert: this is not really a Regions issue but a general question of whether we can have replaced elements that are reflowing

vincent: how do we deal with this issue?

bert: put it on the agenda

<glazou> fantasai: ok with that ?

<scribe> ACTION: alexmog to rework 15811 as a general issue of replaced content and flow [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action05]

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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15858

vincent: the spec identifies the ICB for elements in regions
... the defintiion was modeled on the page spec which uses the first page
... based on use-cases involving a page preview we thought of using the first region as the ICB for the flowed content
... feedback has been that this may not be always useful, and that the normal ICB should be used
... we can also keep what we have
... or we can provide a switch

alexmog: this is also relates to regions' interaction with stacking contexts
... if you model regions based on columns then they're not containing blocks for absolutely positoned elements

anton: it's difficult to understand when you'll want to position within a region or within the wider document. a switch may be too hard to understand

plinss: from past feedback, we may want to be able to declare something to be a containing block
... i like having a switch to control whether an element positions relative to the ICB but it shouldn't be region-specific. It should be in css3-break and apply to pages and maybe columns

vincent: so regions should not discuss this at all

<scribe> ACTION: vhardy to move the issue to css3-break and remove the text from Regions [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action06]

<trackbot> Created ACTION-426 - Move the issue to css3-break and remove the text from Regions [on Vincent Hardy - due 2012-02-14].

Bert: I've found tha the gr unit should be enough to position objects independently of their containing block

steve: if you're simulating multicolumns or something like it, you need a different mechanism

alexmog: you may want positioned elements in your flow to start in a region and cover the next one, you don't want to be constrained by your container or its stacking context.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15116

vincent: I don't have a proposal yet.

<scribe> ACTION: vhardy to update region styling [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action07]

<trackbot> Created ACTION-427 - Update region styling [on Vincent Hardy - due 2012-02-14].

bert: there might potential confusion between styling the region itself and styling on the elements that end up in a region.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15828

<fantasai> glazou: would prefer css3-background / css3-text, save selectors 4 for tomorrow. Or later. I think I need more time to collect my thoughts and dig up examples from www-style

we were missing properties in the CSSOM

<Bert> (If the div defines a grid and has a child p, then 'div::slot(a) {background: red}' sets a bg on the region, while 'p::slot(a) {background: yellow}' sets a bg only on the part of the p that ends up inside that region.)

we added a way to retrive flows by name and return a collection of existing named flows

(previous two comments by vincent)

<glazou> fantasai: I want to have a chance to give my opinion on Tab's Hierarchies during this ftf

tabatkins: I'll suggest a different interface

glazou: <break>

<fantasai> Scribe: fantasai

<vhardy_> ScribeNick: vhardy

Nesting Style Rules

<TabAtkins_> http://dev.w3.org/csswg/css3-hierarchies/

<glazou> http://dev.w3.org/csswg/css3-hierarchies/

<vhardy_> daniel: i want to discuss this because people discovered the document and started to discuss it as if it was a wg draft. I modified it.

<vhardy_> ... it is a modification of the grammar. Technically, it is not in the charter.

<vhardy_> ... it is about nesting rules and reconstructing the selector based on the parent rule.

<vhardy_> ... the goal is to simplify the selector of the children rules. This has been requested for a long time.

<vhardy_> ... I have a lot of issues and questions.

<vhardy_> ... first the OM. Not enough. Selector text on the style rule is not enough.

<vhardy_> ... selector text is not meaningful, you need to reconstruct looking at the parent style rules.

<vhardy_> tab: right now, there is only the nested selector. WOuld be more useful if we provided the expanded the selector, including the parent selectors.

<vhardy_> peter: if you are going to change that, add an attribute to only get the local selector text.

<vhardy_> daniel: there is a way to navigate the children rules from the parent rule, but not from the children rules to the parent rules.

<vhardy_> tab: we are following media queries.

<vhardy_> daniel: you do not say so.

<vhardy_> tab: we are going to say we follow the structure of the @media rules. If something is missing, we will fix both of them.

<vhardy_> daniel: I have a problem with example #5.

<vhardy_> .... the third nested 'thing' have a rule followed by a declaration followed by a rule. This is an issue in the OM, becaues the declaration is stored in one 'thing' and nested rules are in another. Order cannot be maintained.

<vhardy_> tab: I agree you should put your properties first.

<vhardy_> daniel: the order should be mandatory.

<vhardy_> tab: seems fine.

<vhardy_> florian: I noted that the nested things last rather than first works better. That is where they should be if mandatory.

<vhardy_> daniel: you are using the &. That could be an issue for embeded stylesheets because of encoding rules.

<vhardy_> tab: not a problem in HTML.

<vhardy_> daniel: I do not like the & because there are people will forget to use &amp;

<vhardy_> ... I think we should discourage that. I think this is a problem.

<vhardy_> tab: Ok, I'll look for a replacement.

<vhardy_> daniel: editability is a problem. When an editor needs to add a stylerule, you can look for a stylerule with the same selector. With nesting, it is way more complicated. You need to look for a nested style rules as well. It complexifies.

<vhardy_> tab: if you have the full selector, does that simplify your work?

<vhardy_> daniel: when you insert a rule, you have to look for all the rules that have an effect in the cascade and modify them.

<vhardy_> ... I understand this is an important request from the user community, but I would like a clear issue created about editability.

<vhardy_> .... for example, what will happen to legacy browsers.

<vhardy_> tab: they will ignore the nested selectors.

<vhardy_> daniel: will that be used?

<vhardy_> tab: people love that feature.

<vhardy_> jdagget: for things where we have not really taken on a module, could we have a clear marker, something that says this is a 'proposal', not an editor draft.

<vhardy_> tab: yes, that is fine.

<vhardy_> jdagget: the word 'proposal would be ok.

<vhardy_> tab, others: ok.

<vhardy_> steve: moving from proposal to ED is an action of the wg.

<vhardy_> all: yes.

<vhardy_> jdagget: I think this is better to have it here than on someone's blog.

<vhardy_> ... should be a proposal until the group takes it on.

<vhardy_> chris: I did not quite understand the 'expand' the selector thing.

<glazou> http://dev.w3.org/csswg/css3-hierarchies/#nesting-selector

<vhardy_> tab: yes, you have the entire selector.

<vhardy_> chris: then it is duplicated.

<vhardy_> tab: we are talking about selector text in the OM, not in the stylesheet. What is editable is still the short form.

<ChrisL> example 4

<ChrisL> div, p {

<ChrisL> & .keyword, & .constant {color: red;}

<ChrisL> }

<ChrisL> is same as

<ChrisL> div .keyword {color:red;}

<ChrisL> div .constant {color:red;}

<ChrisL> p .keyword {color:red;}

<ChrisL> p .constant {color:red;}

<vhardy_> daniel: In example 4, I would like a change. The parent rule has a group of selectors. The nested rule has a group of selector, if one of the selectors is invalid, the whole is invalid. So use groups in the expanded version of the example.

<vhardy_> tab: changing the example right now.

<vhardy_> daniel: I have a suggestion for editability.

<vhardy_> ... if you set the selector text, the implementation will need to match with as many parent selectors as possible to compute part of the selector only, and set that part of not. If it fails to compute the parent selector, it will throw an error. This is required, because the selector text is writable.

<vhardy_> jdaggett: one way to implement it, then we could do it a parse time only thing.

<vhardy_> (discussion about how this would be the same as the current server side solutions).

<vhardy_> jdaggett: but it would make it easier to manipulate.

<vhardy_> daniel: I do not think this is something we can _not_ do.

<vhardy_> dbaron: I am not happy about the selector text expansion.

<vhardy_> ... it seems a bit lossy in that you might want the thing with the &, it will be hard to get that.

<vhardy_> daniel: the part with the & is the selector text of the parent rule.

<vhardy_> dbaron: no, the local part.

<vhardy_> (all) we are introducing a way to get the local part.

<vhardy_> dbaron: one advantage of making the new one expanded is that we can make it read-only.

<vhardy_> daniel: I do not have a strong opinion, either way.

<vhardy_> ... I just need both for reading and oupting.

<vhardy_> ... to compute the style, I need both.

<vhardy_> ... for writing I only need the local part.

<vhardy_> ... with that, I think editors can work with such a specification, it is doable.

<vhardy_> ... this said, the question is, do we want to work on this?

<vhardy_> ... do we have CSS grammar in the charter for the next 3 years.

<vhardy_> tab: we have other specs, that will modify the grammar or tweak it.

<vhardy_> ... CSS conditionals will do that for example.

<vhardy_> daniel: section 2 of the charter says that CSS syntax is discontinued.

<vhardy_> chris: this just means that draft is not further developed.

<vhardy_> daniel: if we want to work on that, we have to find a landing spot in the existing charter deliverables or extand the charter.

<vhardy_> chris: or we can fit in the existing charter.

<vhardy_> ... syntax is in the scope section, so we are fine.

<vhardy_> daniel: I needed to check that.

<vhardy_> jdagget: the bigger question is the priority.

<vhardy_> ... it is possibly disruptive. There are a lot of things to work out.

<vhardy_> daniel: this is the kind of item that the author community is looking for.

<vhardy_> tab: error recovery rules are working nicely here.

<vhardy_> jdagget: this has a non trivial cost. We already have a lot that we need to get done.

<vhardy_> chris: yes, we have a priority list already.

<vhardy_> ... the important question is the relative priority.

<vhardy_> peter: is there interest from implementors to implement this.

<vhardy_> ... if there is only one implementor, then we will not get to REC.

<vhardy_> florian: from an Opera point of view, I can easily see how people want that, but it is not at the top of our priority list.

<vhardy_> vhardy: we think this is an important feature for web authors.

<vhardy_> sylvain: no plans right now.

<vhardy_> dbaron: there is a bunch of other things that are higher priorities.

<vhardy_> sylvain: selector 4 is more important.

<vhardy_> daniel: I think it is clear there will not be commitment from the wg members to work on this right now.

<vhardy_> peter: do we want to keep this on the shelve as a proposal or do we take it as a WD?

<vhardy_> jdagget: I think we should keep it as a proposal and ask Tab to mark it as a proposal.

<vhardy_> vhardy: what are the more important things?

<vhardy_> ACTION: Tab to mark the nested selector spec. as a proposal. [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action08]

<trackbot> Created ACTION-428 - Mark the nested selector spec. as a proposal. [on Tab Atkins Jr. - due 2012-02-14].

<vhardy_> vhardy: from the feedback we get, nested selectors, mixins and variables are really important.

<fantasai> http://dev.w3.org/csswg/css-line-grid/

Fullscreen

<dbaron> http://lists.w3.org/Archives/Public/www-archive/2012Feb/0004.html

<vhardy_> daniel: Art is asking if we have comments / objections to Web apps working on this.

<vhardy_> chris: I think it should be in web apps.

<vhardy_> tantek: there are presentation aspects, right?

<vhardy_> daniel: yes, there are presentation side effects.

<vhardy_> ... but it is mainly an API.

<vhardy_> tantek: this is already in our charter. Art is asking to propose it for their Web apps charter. Why the extra work to put it in the web apps group.

<vhardy_> chris: Anne is willing to do it in the web apps group and he is a member there.

<vhardy_> daniel: there is, in our charter, to do full screen only for CSS, not in general.

<vhardy_> ... it is not limited to css.

<vhardy_> fantasai: then it should be a joint effort.

<vhardy_> daniel: yes, the css part we do, the api they do.

<vhardy_> chris: while we are talking about this type of cooperation, it strikes me that the CSS OM is that something that should be done as a joint effort between the two groups.

<vhardy_> tantek: I think we have broader dissipation in this group from different companies. From an early exposure to commit patent ip, this group is better than the Web apps group, seeing what happened with touch events.

<vhardy_> ... css wg is better than web apps in that way.

<vhardy_> ... so the work should be done here.

<vhardy_> tantek: the web apps wg does not have as many companies, so if the work is done in the CSS wg, we stand a better chance to get disclosures/exclusions sooner than later.

<vhardy_> ... touch events has been blocked by a patent from Apple.

<vhardy_> ... since they are not in the web apps working group, they could do that.

<vhardy_> tantek: so it is better to do this work, from an IP point of view, in the CSSWG.

<vhardy_> florian: what are the implications of joint work?

<vhardy_> chris: the union of the membership of both groups has the same disclosure obligations over the entire spec.

<vhardy_> tantek: I have no problem co-editing with Anne.

<vhardy_> daniel: my next question: does the group feel taht the argument tantek give about size and IPr rule are the arguments I should present to Art?

<vhardy_> florian: working jointly is the option we should present.

<vhardy_> bert: the argument about members is not strong, because they have Apple and they have companies that we do not have.

<vhardy_> tantek: for example, Flash has a fullscreen API and Adobe is not a member of the Web Apps wg.

<vhardy_> peter: I agree with you, but if you are trying to bring everybody under the tent, then you may force someone out of the tent. This is a risk.

<vhardy_> florian: however, full screen is already in the charter.

<vhardy_> tantek: but hte disclosure requirements happen at FPWD time.

<vhardy_> daniel: so we will propose for a joint effort?

<vhardy_> ACTION: daniel to answer Art about joint work between CSS and Web Apps WG on fullscreen CSS and APIs. [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action09]

<trackbot> Sorry, amibiguous username (more than one match) - daniel

<trackbot> Try using a different identifier, such as family name or username (eg. dglazman, dweck2)

Schedule for Snapshot 2012: end or start of the year?

<vhardy_> peter: last time we discussed it, we said we would do a snapshot every year.

<vhardy_> bert: is that what worked before 2012 or starting 2012?

<vhardy_> chris: if you publish at the end of 2012, then people think they are dealing with an old spec.

<vhardy_> fantasai: we can publish at any point, but the question, is, do we expect to add things to the snapshot (and have test suite).

<vhardy_> .. I think we are just going to republish with a new date.

<vhardy_> dbaron: 2d transform could be there.

<vhardy_> peter: media queries.

<vhardy_> tab: images will have a test suite.

<vhardy_> fantasai: we also need at least an implementation that passes most of the testsuite and failures understood.

<vhardy_> chris: this is still a prediction: we expect things to get out of CR soon.

<vhardy_> fantasai: yes, e.g., MQ made it because we understood the failures and there was a test suite and implementation.

<vhardy_> chris: if the point is to publish one every year, then we would sometimes republish the same thing.

<vhardy_> peter: we should publish at least once a year. We may publish several times a year.

<vhardy_> ... it is just a note about the current state of the world and we update as necessary but at least once a yaer.

<vhardy_> steve: we need to indicate some level of stability, but publishing a new number if there is no changes is not useful.

<vhardy_> peter: i think there is a benefit.

<vhardy_> ... if there isn't one that is current, which one do you look at?

<vhardy_> steve: the most recent one.

<vhardy_> peter: this is the problem with open type projects. If something is not updated, you do not know if this is because people did not publish the update or because nothing is happening. This has value.

<vhardy_> steve: ok, understood.

<vhardy_> peter: so I would like to publish snapshot 2012 asap and we will republish immediately if new things are eligible.

<vhardy_> bert: I think that is too often.

<vhardy_> ... publishing often seems unstable.

<vhardy_> chris: we need to communicate that the stability state has changed.

<vhardy_> bert: ... people can wait 6 months.

<vhardy_> chris: we give people a short spec. that says what is stable.

<vhardy_> peter: the snapshot is a note, it is easy to publish. It is for communication.

<vhardy_> tantek: I think we should update the snapshot everytime a spec. goes to CR.

<vhardy_> several: that is not the criteria, the criteria is that the spec. is almost ready to exit CR.

<vhardy_> steve: once a year is fine.

<vhardy_> tantek: I propose to publish at the begining of the year.

<vhardy_> several: yes.

<vhardy_> RESOLUTION: the CSS snapshot will be published once a year, at the begining of the year, and every time a new specification meets the criteria for being listed in the snapshot note.

<vhardy_> ACTION: Fantasai to publish snapshot 2012 ASAP> [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action10]

<trackbot> Created ACTION-429 - Publish snapshot 2012 ASAP> [on Elika Etemad - due 2012-02-14].

Media Queries REC http://lists.w3.org/Archives/Public/public-css-testsuite/2012Jan/0001.html

<vhardy_> fantasai: we need an implementation report.

<vhardy_> florian: what is the status of the test suite?

<vhardy_> peter: it was being reworked.

<vhardy_> fantasai: that does not make the tests invalid.

<vhardy_> chris: this is a case of what you use for generating the report.

<vhardy_> (history of the test suite and who contributed).

<vhardy_> peter: the test suite has sufficient coverage of the spec?

<dbaron> http://www.w3.org/Style/CSS/Test/MediaQueries/20100726/

<ChrisL> http://www.w3.org/Style/CSS/Test/MediaQueries/20100726/

<vhardy_> dbaron: I think we need to publish a new snapshot of the test suite.

<vhardy_> ACTION: fantasai to publish a new snapshot of the MQ test suite. [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action11]

<trackbot> Created ACTION-430 - Publish a new snapshot of the MQ test suite. [on Elika Etemad - due 2012-02-14].

<plinss> MQ test suite source: http://hg.csswg.org/test/file/tip/contributors/anne/submitted/mediaqueries

<vhardy_> daniel: implementation reports by?

<vhardy_> Mozilla, Opera

<vhardy_> ACTION: dbaron to provide an implementation report for the MQ test suite. [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action12]

<trackbot> Created ACTION-431 - Provide an implementation report for the MQ test suite. [on David Baron - due 2012-02-14].

<vhardy_> ACTION: florian to provide an implementation report for the MQ test suite. [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action13]

<trackbot> Created ACTION-432 - Provide an implementation report for the MQ test suite. [on Florian Rivoal - due 2012-02-14].

<ChrisL> testing Opera.next Version

<ChrisL> 12.00 alpha

<ChrisL> Build

<ChrisL> 1272

<ChrisL> Passed: 254

<ChrisL> Failed: 107

<vhardy_> ACTION: smfr to provide an implementation report for the MQ test suite. [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action14]

<trackbot> Created ACTION-433 - Provide an implementation report for the MQ test suite. [on Simon Fraser - due 2012-02-14].

<vhardy_> ===== LUNCH BREAK ======

<smfr> http://wiki.csswg.org/planning/paris-2012

<fantasai> Scribe: fantasai

WebKit Prefix Conversations

plinss: Had various offline conversations.
... Tantek / roc talking about creating this list of properties they're considering for webkit prefixing
... Would like that list given to WG ASAP
... Rather than vendors making blog posts saying "this is what we're going to do", would rather vendors brought these lists to us so we can reset our priorities
... There is market interest in these properties. They are ready to be implemented, or already implemented, interoperably by multiple vendors. Therefore they meet the criteria to be standardized
... No reason they shouldn't be standardized immediately.
... If vendors feel there is sufficient market pressure tha it's rucial to their business, that should be our highest priority.
... So I would like to get buy-in from the group that this is the right approach.
... Would like commitment from vendors considering this to talk to us, let us address this as quickly as possible.

Florian: I'm convinced this is a good idea. Concerned it's not sufficient, but regardless we need to do it.

plinss: I accept it may not be sufficient. I hope it is. But we should as a WG do what we can to alleviate this market pressure.
... Asking for commitment to get this list from vendors asap, and bring it first to WG not to vendor blogs

glazou: .... expand the evangelism commmunity.
... let's try everything before going to the last resort
... I have two options for the article. Can call community at large.

Florian: Idea is a call to the community at large to be responsible for how they use prefixes.
... vendors have tried that on their own, he's suggesting to do it together.

plinss: I think if we have 2-3 vendors effectively agree on an implementation, whether it's because they like it or they're locked into it, that's sufficient for us to declare that it's enough for us to drop prefixes.
... Then we can call on all sites to drop prefixes.

glazou: Want to move from de facto to de jure standards.

tantek: Daniel, such an article might help. Need to point out 2 things.
... First, point out that -webkit- is hurting the web.
... 2 problems. First is UA-sniffing, only providing modern web content to webkit
... 2nd problem is that there are numerous features that work effectively interoperably across browsers
... That if those sites put multiple prefixes today, without any change from this group, they would work.

glazou: Even if we're not sure that it will work, I think it is worht trying. I don't want us to take last resort option without trying.

tantek: We'd rather sites provided full content to Mozilla and have it break, than provide dumb content to us. I think we're fixing things fast enough that we can respond to that. But it's the webkit-only coding that is harmful.

glazou: Let's suppose it works a bit, and you see a trend of websites adding properties and not sniffing. Will that be sufficient for you to decide to wait?

tantek: Will look at data on a case-by-case basis. If data changes, conclusions may change.

plinss: Need to tackle this on all fronts.
... Need to evaluate list of properties, resolve to drop prefixes for those that are ready.

tantek: I don't want to provide a list of properties, because I don't want anything that developers can depend on.

fantasai: What about providing a list to the CSSWG list?

tantek: Might change over time.

Florian: Peter asked for the list to set priorities.

Alan: Should emphasize that can use all prefixed versions right now, and without any changes by us, will work today.
... And we should be trying to drop prefixes on the things that work in that way.

Tantek: We already have that focus in the WG. But things that are outstanding measures in the WG.
...

plinss: The moment you have sufficient data about one property. If nothing else, send it to Daniel and I, so that we can make it #1 priority on the next telecon.
... My assertion is, just like we were driving 2.1 to REC, that was highest priority. I'm offering you and Opera and MS, that level of priority if you get to that point on any property.
... That will be the #1 focus of the group to drop that prefix.

tantek: Ok. I'm willing to put that on css-wg list. Don't want to kick of some kind of flamewar on www-style. Minutes of discussion will of course be public.
... We may wind up posting list to wiki page, but we have better things to do than write blog posts aobut it.

plinss: If we can help the situation by dropping the prefix, we will drop the prefix.

<ChrisL> pointer to prefixing policy doc?

<smfr> http://www.w3.org/TR/CSS/#experimental

fantasai: Note that we do have a loophole in the vendor-prefixing policy that the WG can declare an experimental property to be implemented prefixless *for legacy reasons*. This was originally for things like text-overflow, but existing webkit-only content on the web also qualifies as a legacy reason.
... So if we have a spec that we cannot move fast enough to CR, we can use that loophole to drop prefixes immediately.
... [says stuff]

smfr: [1-3 months]

fantasai: Will that happen?

smfr: We can make that happen.

Tantek: How about we go to CR with open issues?

fantasai: What's the point of that? The CR transition requires no open issues. If your problem is you want to drop prefixes with open issues, then drop prefixes before CR.

jdaggett: You can defer issues, e.g. mark things undefined.

Tantek: ... You'll get issues faster than you can evaluate them, just like 2.1

fantasai: We haven't had that problem to the extent we had it with 2.1 with our CSS3 modules
... What do you want out of moving to CR?

Tantek: Dropping prefixes

fantasai: So let's drop prefixes and not change the definition of CR, what's the problem?

Tantek: ...
... I think it's more important to use CR as a marker for dropping prefixes than a marker for closing issues.
... ...

plinss: To make progress faster, as a group, we can drop prefixes before CR. And if there's a singificant portion that is stable and has no issues, is ready to go to CR, we split the spec.
... And we are also willing to run through issues and solve or defer them quickly.
... We have three different avenues and we're willing to use them all as needed.

Tantek: Sounds good.

Backgrounds and Borders

<TabAtkins_> ScribeNick: TabAtkins_

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

fantasai: Bert and I have been going through the B&B issues.
... There are a couple open ones, with proposed reoslutions, but we need the WG to evaluate them.
... First is bidi reordering and the application of box-decoration:break

<fantasai> http://dev.w3.org/csswg/css3-background/#the-box-decoration-break

fantasai: After the discussion with dbaron, I edited in text that says UAs *may* apply box-decoration to control rendering at bidi-imposed breaks.

<fantasai> "UAs may also apply ‘box-decoration-break’ to control rendering at bidi-imposed breaks, i.e. when bidi reordering causes an inline to split into non-contiguous fragments. Otherwise such breaks are always handled as ‘slice’. "

fantasai: Otherwise, such breaks are handled as slice.
... Are people happy with this?

TabAtkins_: Is there a particular reason to keep it optional right now?

dbaron: We don't have a strict definition of where bidi breaks happen.
... And we probably, in reality, want to split breaks into two groups, one of which pays attention ot the property, and the other which always slices.

fantasai: This is a weird edge case, so this lets the UA do whatever makes sense right now.
... The default behavior is 'slice' (the easy case), so the suggested solution is to optionally apply 'break' when specified if the UA has a good way to do it.

dbaron: Is it conformant to do a split between the two?

fantasai: I don't think it's conformant with this wording.

dbaron: I think it's the most sensible behavior, at least given by the way we consider these breaks to exist.

fantasai: That's why we have the term "contiguous".

dbaron: I want tests in the test suite for this.

fantasai: Ok.

[no further objections]

fantasai: Next issue is the corner transitions in border-radius

<fantasai> http://dev.w3.org/csswg/css3-background/#corner-transitions

fantasai: The spec as I brought up before is *completely* wrong. But we don't have a good definition for the right behavior, so the idea right now is to make it officially undefined for now.

<fantasai> Color and style transitions must be contained within the segment of the border that intersects the smallest rectangle that contains both border radii as well as the center of the inner curve (which may be a point representing the corner of the padding edge, if the border radii are smaller than the border-width).

<fantasai> If one of these borders is zero-width, then the other border takes up the entire transitional area. Otherwise, the center of color and style transitions between adjoining borders must be proportional to the ratio of the border widths such that a function of its location is continuous with respect to this ratio. However it is not defined what these transitions look like or how “proportional” maps to a point on the curve.

fantasai: This way, the spec is at least not *wrong*, and we can figure out the correct behavior in level 4.
... [explains the above text]

plinss: Didn't we discuss this at TPAC?

fantasai: We did, and concluded we needed to investigate a lot more before we could correctly specify it.
... This way, we're defining the important bits that people rely on.
... Like that a zero-width border won't contribute any visible color.
... And that larger borders are proportional in some way.

sylvaing: What's the important bit, precisely, and who depends on it?

fantasai: One example is a box with only a border on top that curves around. The sides will usually just be currentColor, and authors don't expect that to show up.

tantek_: I think we could instead hook that to border-style. If the side is border-style:none, don't show any of the dest color. But if it's solid, even if it's 0px, when you do a gradient it should fade to that.

Bert: I think that's what Konqueror does.

<fantasai> fantasai: So you want to replace 'zero-width' with 'none or hidden'.

dbaron: I think that removes the continuity argument.

Bert: Not sure. We need more research, or to leave it open.

tantek_: I'm okay with leaving it open, I just wanted to present it as a use-case.

fantasai: So if you wanted to use a double or dashed border...

tantek_: Borders historically have been places where we allow impls to give better results, rather than locking them into an LCD.

fantasai: So we still want to define, at least in the 'none' case, that the entire visible border is the color of the non-'none' border.
... But that makes dbaron unhappy.

dbaron: I don't think the color at the corner is ever what's desirable.

fantasai: So how should we resolve this?

dbaron, smfr: I'm happy leaving it as it is.

plinss: Can we resolve to accept the text in the editor's draft?

[no objection]

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

fantasai: Next issue, define the default shadow color.

RESOLUTION: Accept the ED text for border-transitions.

RESOLUTION: Accept the proposed resolution for bidi splits and box-break

<fantasai> Options mentioned so far:

<fantasai> - black

<fantasai> - rgba(0,0,0,0.5)

<fantasai> - currentColor

<fantasai> - currentColor except it doesn't compute until after inheritance

<fantasai> - make <color> required

fantasai: There's a bunch of options: 'black', 'rgba(0,0,0,.5)', 'currentColor', 'currentColor, but used-value time', or require it be defined.

dbaron: Are we discussing box-shadow, or text-shadow as well? And what do the specs currently say?

fantasai: Both, and they shoudl be consistent. They both say "UA defined" right now.

dbaron: Gecko seems to use currentColor for both shadows, almost.
... I think, though, that on text-shadow, if the text decorations are a different color form the text, the default shadow *on the decorations* will match the decoration color.

<fantasai> fantasai: Ok, so 6 options (for text-shadow; doesn't make a difference for box-shadow)

plinss: Any opinions?

<dbaron> data:text/html;charset=utf-8,<!DOCTYPE html><span style%3D"text-decoration%3A underline%3B color%3A blue"><span style%3D"text-decoration%3A overline%3B color%3A fuchsia%3B"><span style%3D"color%3A orange%3B text-shadow%3A 20px 20px">hello<%2Fspan><%2Fspan>

dbaron: Above data url confirms Gecko's text-shadow handling.

smfr: I think WebKit defaults to transparent.

fantasai: We could still make it required.

dbaron: I'm not comfortabl ewith a syntax change at this point.
... Opera doesn't shadow decorations at all.

<fantasai> Tab: When we do equivalent of fill on text, filling text with images, what will text-shadow do then?

<fantasai> Florian: Will it behave like stained glass or not?

<fantasai> smfr: I think black as a default color would be easier to understand.

<fantasai> Tab: Given we have random answers right now, we could pick anything.

<dbaron> data:text/html;charset=utf-8,<!DOCTYPE html><span style%3D"text-decoration%3A underline%3B color%3A blue"><span style%3D"text-decoration%3A overline%3B color%3A fuchsia%3B"><span style%3D"text-decoration:line-through;color%3A orange%3B text-shadow%3A 20px 20px">hello<%2Fspan><%2Fspan>

<fantasai> [people run tests on various UAs]

sylvaing: IE10 shadows text and decorations both with the currentColor.

<fantasai> [discussing defaulting to black]

<fantasai> Bert: we have an implementation: Konqueror defaults to black

<dbaron> http://www.w3.org/TR/1998/REC-CSS2-19980512/text.html#text-shadow-props says to use the current color

[everyone checks what the default for box-shadow is in UAs]

<dbaron> data:text/html;charset=utf-8,<!DOCTYPE html><span style%3D"text-decoration%3A underline%3B color%3A blue"><span style%3D"text-decoration%3A overline%3B color%3A fuchsia%3B"><span style%3D"text-decoration:line-through;color%3A orange%3B text-shadow%3A 20px 20px;box-shadow: 40px 40px">hello<%2Fspan><%2Fspan>

<fantasai> Proposed to make box-shadow default to the value of the 'color' property on the element being shadowed. computed value doesn't have a color if it's not specified.

<fantasai> RESOLVED: box-shadow as above

fantasai: We fixed some definitions surrounding border-image and SVG. We need review to ensure they're correct.
... [explains the text in the spec]

<fantasai> http://dev.w3.org/csswg/css3-background/#the-border-image-source

<fantasai> If the image must be sized to determine the slices (for example, for SVG images with no intrinsic size), then it is sized as for an auto-sized background, using the border image area as the default object size in place of the background positioning area.

fantasai: If the image has an intrinsic size, you don't need to size it to cut it.

ChrisL: It won't tile in the sense tha tyou have only one copy of the image.

dbaron: It seems there may be a solution wher eyou just end up with one copy of the imgae.
... Except you're doing sizing before doing slicing to fill the border.

Summary of Action Items

[NEW] ACTION: alexmog to rework 15811 as a general issue of replaced content and flow [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action05]
[NEW] ACTION: daniel to answer Art about joint work between CSS and Web Apps WG on fullscreen CSS and APIs. [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action09]
[NEW] ACTION: dbaron to provide an implementation report for the MQ test suite. [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action12]
[NEW] ACTION: fantasai to publish a new snapshot of the MQ test suite. [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action11]
[NEW] ACTION: Fantasai to publish snapshot 2012 ASAP> [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action10]
[NEW] ACTION: florian to provide an implementation report for the MQ test suite. [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action13]
[NEW] ACTION: smfr to provide an implementation report for the MQ test suite. [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action14]
[NEW] ACTION: Tab to mark the nested selector spec. as a proposal. [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action08]
[NEW] ACTION: vhardy Create a shared directory to post the bug helper script and document it on the wiki [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action02]
[NEW] ACTION: vhardy Draft a page template proposal for the May f2f [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action01]
[NEW] ACTION: vhardy make a generic use-case page linking to proposed markup solutions [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action03]
[NEW] ACTION: vhardy Make item 4 a multicolumn overflow [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action04]
[NEW] ACTION: vhardy to move the issue to css3-break and remove the text from Regions [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action06]
[NEW] ACTION: vhardy to update region styling [recorded in http://www.w3.org/2012/02/07-css-minutes.html#action07]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/02/07 14:22:32 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/proposal/use-cases/
Succeeded: s/joined/joint/
Succeeded: s/not/no/
Succeeded: s/thinjk/think/
WARNING: No scribe lines found matching ScribeNick pattern: <fantasai> ...
Found ScribeNick: sylvaing
Found Scribe: fantasai
Found ScribeNick: vhardy
Found Scribe: fantasai
Inferring ScribeNick: fantasai
WARNING: No scribe lines found matching previous ScribeNick pattern: <vhardy> ...
Found ScribeNick: TabAtkins_
ScribeNicks: sylvaing, vhardy, fantasai, TabAtkins_

WARNING: No "Present: ... " found!
Possibly Present: Alan Bert CGI232 ChrisL Failed Florian Ms2ger Passed Rossen TabAtkins TabAtkins_ alex alexmog alexmog_ alexmog__ all anton antonp astearns chris css daniel data dbaron dglazkov drublic fantasai glazou glenn howcome https jdagget jdaggett jet joined karl kojiishi left lhnz peter plinss scribenick several smfr steve sylvain sylvaing szilles tab tantek tantek_ trackbot vhardy vhardy_ vincent
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


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: 07 Feb 2012
Guessing minutes URL: http://www.w3.org/2012/02/07-css-minutes.html
People with action items: alexmog daniel dbaron fantasai florian smfr tab vhardy

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]