W3C home > Mailing lists > Public > www-style@w3.org > August 2011

[CSSWG] Minutes and Resolutions 2011-08-29

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 29 Aug 2011 01:26:11 -0700
Message-ID: <4E5B4D23.6060103@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - RESOLVED: publish CSS3 Text and CSS3 Writing Modes as WDs with updates
               mentioned in minutes
   - Deferred Selectors 4 publication until Selectors 3 hits REC in a couple weeks
   - RESOLVED: use flow-from property to enable regions, mark interaction with
               'content' and 'display' as an issue
   - RESOLVED: CSS Regions has a region break like multicol and start on css3
               pagination module and Mozilla/Adobe/MS would sort out the editorship
               of that spec
   - RESOLVED: TabAtkins to create a proposal for print bgs

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

     Tab Atkins
     Arron Eicholz
     Elika Etemad
     Arno Gourdol
     John Jansen
     Peter Linss
     Divya Manian
     Alex Mogilevsky
     Edward O'Connor
     Florian Rivoal
     David Singer
     Alan Stearns
     Steve Zilles

   <RRSAgent> logging to http://www.w3.org/2011/08/24-css-irc


   plinss: anyone else has anything to add to the agenda?

Publishing Writing Modes and Text

   plinss: bunch of publishing requests
   plinss: css3-texts and writing modes.
   SteveZ: John sent a note about writing modes
   florian: the wording is not strong enough about being an unresolved
            problem here and he put out an alternative wording
   fantasai: is that something I can fix and publish? or should I hold off?
   SteveZ: the wording was only two sentences. Cant speak for John
   florian reads from the email
   fantasai: that is not actually possible. we can get close to it but there
             is a problem with characters like quotes, where default orientation
             needs to be upright if the font supports vertical and sideways
   stevez: that is not how vertical tables work
   stevez: that is separate. you can't expect a vertical table to tell you what
           to do for the orientation
   florian: we agree there is a difficult problem here, rather than saying we
            "may" try we should say we "will" try.
   florian: it is not guaranteed that we will successfully find a solution.
   stevez: John publsihed a test case that shows that there is no uniform
           implementation across browsers, and none of the existing unicode
           properties would allow you to map to the upright characters. The
           point being there is no simple solution and can't say what the
           browsers do, and cant say do what unicode does.
   stevez: there is a separate effort to define a unicode property to define
           implementation, but thats separate.
   fantasai: we currently use Unicode properties to group most characters
   fantasai: but we have a very long list of exceptions.
   fantasai: and in some cases we do not have a good answer yet.
   plinss: are we in agreement with John's sentiment here?
   plinss: anyone opposed to that.
   plinss: I take that as a consensus
   florian: I am not sure about how to resolve the issue, but I am with him on
            the concern on that.

   fantasai: I would like to take a quick look at florian's issue.
   fantasai: I have a patch for that I want to check with the rest of the
             people here before I check that in.
   florian: I have not been able to look at my mail last weekend
   fantasai: I linked to it from my message requesting publication.
   <florian> http://lists.w3.org/Archives/Public/www-style/2011Aug/0427.html
   florian: there are 2 types of values in text-combine-horizontal property.
   florian: I am suggesting we can split these into two properties. The visual
            effect of squeezing text in is likely to be the same across document
   florian: but not what is being squeezed
   florian: if you split them it would reduce repetition
   florian: I do not have a good name for that.
   florian: what do people think about the idea.
   szilles: I have not thought about it, what you are saying makes sense. I
            prefer in general binary switch for turning things off and on,
            and a different property for the variance
   florian: that's my idea as well
   plinss: do we have any suggestions on this?
   florian: so we agree to split?
   fantasai: I put 'text-combine-mode' in my draft
   florian: it's better than what I said
   plinss: are we happy to publish with that change?
   szilles: yeah, it is still a draft
   szilles: I think the principle that florian is espousing is a good principle
   RESOLVED: publish CSS3 Text and CSS3 Writing Modes as WDs with updates mentioned

   florian: Wrt details of text-combine, I am convinced the wording we now
            have is a good representation of the conclusion we reached at F2F.
            so that is solved as far as I am concerned.

Selectors 4

   plinss: when are we going to publish the first draft of Selectors 4.
           W3C decided to wait until namespaces is out. Should we wait
           until selectors 3 is a REC or decide to publish it now?
           Anyone has strong opinions on that?
   arronei: with selectors 3 is it just held up by namespaces right now?
   szilles: you get less confusion if you wait and publish selectors 4
            after the 3 REC goes out
   plinss: I agree, but I am not sure if its that big of a deal
   florian: I think we said the same thing at last f2f. as long as selectors 3
            went to REC quickly then we have no issue, how long as we willing
            to wait.
   plinss: did you see note about updating drafts for epub?
   fantasai: I don't know if fonts draft needs to be published or not.
   plinss: we will discuss those two over email and get some feedback from
           the editors (who are not here)


   plinss: display-inside and content property
   plinss: where are we on this
   alexmog: we had a conversation with vhardy we have not agreed on a resolution.
   alexmog: my issue is using content it has a lot of meaning and behaviour
            in generated content as it interacts with model of ::before and
   alexmog: the use of that kind of content, might change the meaning of the
            element it is in and blows away before and after and we do not mean
            that content property
   alexmog: display property could be one way to do that or a separate
            from-flow property
   alexmog: if we had a display-inside property it would say display-inside:
            region and something else that would say where content comes from.
            It may be content property
   szilles: we have talked about having a region be a multicol, which is why
            I am not happy about display-inside: region. I like the principle
            of having a separate property that turns something into region and
            then say what properties apply to region rather than putting of
            content in it turning on.
   alexmog: multicol will be display-inside if display-inside existed
   szilles: why not create a diff property with region yes/no with no as default
   vhardy: we could also go with the option of alexmog which is you have a
           flow-from property which would be what you are asking for and also
           say which region you are applying content form. The only tweak from
           your proposal, alex, is that ::before and ::after work on a region
   vhardy: we would be okay using flow-from proposal as it is close to what
           szilles is saying
   szilles: yes and no. it is using to say where text comes from to turn it
            into a region and I was trying to separate those two, but I am
            not strongly of any position. I can live with either
   alexmog: similar to float: positioned which we used to trigger exclusions
            and appears redundant as you also have to use wrap-type everytime
            you use that property.
   alexmog: so we ended up adopting adobe's solution, and here we use the same
   szilles: it is a valid point, and I can live either way
   fantasai: I think having two properties seems like too many levels of
   vhardy: I propose we try to resolve on flow-from and having before and after
           work with current pseudo selectors
   TabAtkins: what happens when you do flow-from form elements that is also
              a grid or flexbox
   vhardy: we have a resolution that says you can only turn something into a
           region if it is a block container box
   TabAtkins: the reason I wanted display-inside was to prevent unwanted
   TabAtkins: it is similar to what columns do.
   fantasai: still concerned about the interaction but have nothing concrete
             to say
   fantasai: interaction with display, and the content property as we are
             overriding with a different property
   alexmog: flow-from has a very diff meaning from content
   alexmog: content overrides WITHIN the element.
   <bradk> What if we had content:flow-from() take the children of the named
           element, instead of the item itself?
   alexmog: flow-from overrides everything.
   alexmog: that is inside this element. it does not change the meaning of
            content. it just replaces everything within.
   fantasai: content property was intended to control what the contents are,
             and now we have another property that does essentially the same
   fantasai: the most obvious thing that is changing is the contents of the
             element are not being displayed in favour of something else.
   fantasai: seems like a problem to me.
   * hober agrees with fantasai
   vhardy: I think it is slightly different
   vhardy: you specify what content goes into the element
   vhardy: pull the content and this will be figured out at layout.
   alexmog: what content property does is replaces the content of the element
   alexmog: flow-from does is what the box is showing
   plinss: I had a proposal in kyoto we use flow-from property and then use
           content property
   plinss: maybe we need another keyword to access actual content of the
           element rather than the flow content
   fantasai: the initial value of content property is normal, so normal
             computes to diff things depending on what the element is
   fantasai: it computes to list marker on a list marker, etc
   <bradk> content:flow-from() could replaces the content of the element
           with the contents of the flow.
   plinss: normal could compute to flow-from on elements that have a flow-from
   vhardy: I am not sure I understand what this means
   szilles: the normal behaviour of content could be if you have flow-from,
            use it.
   plinss: if you say flow-from and content, content wins so you have a
           keyword within content.
   alexmog: I think flow-from should win
   fantasai: I don't want to hold off progress on resolving other issues.
             I don't want to consider this resolved, but I am fine with
             picking a solution and working with it.
   vhardy: what is the solution we are going for?
   alexmog: I completely disagree with that
   * nimbupani agrees with alexmog
   szilles: if you want to be able to use ::before and ::after you want to
            fit it into the model
   alexmog: ::before and ::after does not feed into region flow
   szilles: vhardy said he would like to feed into the regions model
   alexmog: I don't know what it would mean to have content ::before that is
            float right and have that merge with multicol flow
   vhardy: the feedback I got was that we should specify the behavior of
           ::before and ::after when element is a region
   alexmog: for ::before and ::after that would be special meaning do something
            different when they apply to a region
   szilles: it isn't completely different which is why people suggest we use it
   vhardy: can we go with doing a new iteration on ED using flow-from and
           trying to resolve what we can do with before/after
   vhardy: plinss you talked about using another keyword to define actual
   vhardy: plinss you talked about using another keyword to define actual content.
   plinss: the proposal in kyoto, there is a separate proposal on adding a
           'contents' keyword so you can combine the content that is already
   plinss: I dont know if we need that, that was a separate proposal
   vhardy: for now we can live without that.
   szilles: I think it would be useful to put the issue under flow from that
            we need to clarify the interaction between the fow from and the
            content property.
   vhardy: I was proposing to say something in the draft
   vhardy: we iterate on the draft and have a new ED proposed for the next F2F,
           and we can have an issue on the review of the new WD.
   alexmog: lets keep it an issue.
   <alexmog> have we resolved "use 'flow-from' property to enable regions,
             add an issue to the draft to define interaction with 'content'
             and 'contents'" ?
   RESOLVED: use flow-from property to enable regions, mark interaction with
             'content' and 'display' as an issue

   vhardy: following the resolution about breaks to be container specific or
           region specific as decided on Seattle, I aligned it with multicol.
   vhardy: issues I raised on seattle meeting are not region specific they
           affect multicol pagination as one thing
   vhardy: how do breaks work in nested regions, multicol and when you start
           combining different kinds of break. it spans regions multicol and
   vhardy: I dont think this is the right place to handle in the regions spec.
           what do we do about it? do we have a separate spec for breaks?
   alexmog: my biggest concern with region break was that while behavior of
            page-break is undefined we would be creating a separate syntax
            for something that means something exactly same as page break or
            has same effect in same media
   plinss: we redefined breaking property in multicol
   vhardy: we already resolved to have a region break
   florian: when we want diff kind of break for diff kind of thing and we
            need to think about carefully.
   fantasai: we need a css3 pagination module?
   vhardy: maybe.
   alexmog: yeah that would be great to have one. we can ask for volunteers
            to write it.
   fantasai: there is some interaction with Paged Media spec.
   fantasai: we might want to sync paged media spec to css 2.1 and push that
             out and have css3 pagination and then add whatever we need to add
   fantasai: the multicol spec defines aliases it was kinda expecting paged
             media to do that definition
   fantasai: maybe we can pull that into a separate module
   vhardy: sgtm
   plinss: who is going to work on the pagination module
   fantasai: I probably should do that
   fantasai: I hope its okay if I don't start until sept or oct
   fantasai: will be working more on pagination stuff this fall in either case.
   alexmog: MS and Adobe are most motivated people so maybe we and you should
            talk about it and figure out who should write the spec
   vhardy: yeah
   fantasai: Paged Media needs to go to CR mostly as-is, featurewise.
   fantasai: But I can copy out various pieces we need from paged media and
             create a framework
   RESOLVED: CSS Regions has a region break like multicol and start on css3
             pagination module and Mozilla/Adobe/MS would sort out the editorship
             of that spec
   <vhardy> http://dev.w3.org/csswg/css3-regions/#region-flow-break-properties-break-before-break-after-break-inside

Topic Switch

   plinss: Conformance markup within the spec
   TabAtkins: can we talk about print backgrounds
   fantasai: can we talk about css 2.1 test suites?
   plinss: whats the issue?
   fantasai: apparently Gérard Talbot filed a bunch of issues but has not
             received a response about getting them fixed
   fantasai: is MS planning to maintain those tests or do we need to find
             a new owner?
   arronei: I can make changes whenever we feel its right
   plinss: no reason not to make updates.
   arronei: I can start working on it then

Printing Backgrounds

   <florian> http://wiki.csswg.org/ideas/print-backgrounds
   plinss: TabAtkins is saying if we can get a resolution in printing bg
           last week
   TabAtkins: wiki page did not facilitate new discussion
   TabAtkins: 1. do nothing
              2. add a hint that lets author provide extra info so UA can
                 make a better choice
   florian: 1 and then come up with a UI that lets user switch based.
   TabAtkins: are you asking me to come up with a new browser UI for all browsers
   florian: seems like browsers have not made effort on print yet. Option 1
            is not silly and use ?? as heuristics it is not that silly
   plinss: there is no way we can get reasonable heuristics. And there are print
            scenarios that do not have a direct user interaction
   ??? I like whats in 3
   alexmog: using !important
   TabAtkins: !important is already doing wrong things and it is not just bgs.
   alexmog: printing bgs is unique situation where browser refuses to display
            something that was specified. it is a special feature
   alexmog: there is no other issue like that. we can create !print
   fantasai: we should have the principle that if someone has done the right
             thing, they should do one simple thing and it should just work
   fantasai: they should not have to rewrite the stylesheet
   fantasai: !important does not fit that bill
   alexmog: what is your preferred answer, TabAtkins
   florian: are we aligning with prop 7?
   <florian> I was just asking fantasai's position, not everybody's
   plinss: print media stylesheet is not sufficient
   TabAtkins: 2 to 6 are unusable
   TabAtkins: I am for option 7
   alexmog: is this for document or elements
   TabAtkins: either way
   TabAtkins: putting on doc is 7.1
   TabAtkins: individual pages is 7.2
   TabAtkins: any of them works.
   alexmog: it could be a meta tag
   arronei: print or anything like that says we know better than you. the
            user needs to decide.
   arronei: as vendors we decided not to print bgs by default. if we decide
            to print bgs by default, we need to engage the community and
            teach authors that they need to author good stylesheets for print
   TabAtkins: we will not be changing browsers to print bgs by default
   arronei: now you need to provide a notification that you will be printing
            insane amount of stuff on these pages.
   ???: we need people to write good stylesheet
   alexmog: if we add an option to print bg we will never need user override
            with that.
   <dsinger> printed backgrounds sometimes make the print unreadable
   alexmog: browser it is okay to print what the author has done that. the lack
            of the property means this is the old page and use it the old way.
   <dsinger> making users miserable with the default is no way to educate site
             authors to make better stylesheets
   fantasai: an interesting heuristic to check would be if canvas has a bg
             that is not white then probably the page is not designed to
             print with ink
   plinss: I dont think the simple heuristic is good enough.
   <oyvind> I'm sure plenty of pages have white/transparent html/body and
            put everything in some div
   TabAtkins: I have designed pages with no canvas bgs and elements that span
              the canvas having bg
   dsinger: bg by default would make users miserable
   <alexmog> <meta http-equiv="X-UA-Print-Background" content="always"/>
   <szilles> I support Alex's point: that adding a flag, probably on the
             document, that says honor the style, would allow migration to
             using suitable 'print' stylesheets
   TabAtkins: are we going to make a decision or are we going to continue be
   TabAtkins: we are unable to make any decision on this whatsoever
   alexmog: we are closer to a decision
   TabAtkins: don't do it at all or do it with a property, there is no useful
              conversation out of this. I am not sure how to proceed.
   TabAtkins: I am not seeing any progress towards a conclusion
   alexmog: you have proposal on the wiki
   alexmog: we can have things that are not in css but apply to whole doc
   TabAtkins: if we decide there is a mechanism for this, that would be
              sufficient for my needs.
   TabAtkins: can we assume 7 covers all variations on this idea?
   plinss: I propose we elect to do something
   plinss: I think we should move forward anyway.
   plinss: tab should work on a concrete proposal get some implementation
           experience and if folks hate it we can revisit
   <szilles> +1 for Peter's proposal
   TabAtkins: cool for me
   RESOLVED: TabAtkins to create a proposal for print bgs
Received on Monday, 29 August 2011 08:27:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:03 UTC