- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 29 Aug 2011 01:26:11 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- 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 ======
Present:
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
Administrative
--------------
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
otherwise
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)
Regions
-------
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
::after.
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
indirection.
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
interactions.
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
thing.
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
content.
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
there.
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
pagination
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
undefined
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