- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sat, 28 Jan 2012 00:47:58 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Discussed posting agendas to www-style
- Discussed adding CSS2.1 to F2F agenda
- Discussed scriptability media query
- Discussed whether to add color math functions
- Discussed device-pixel-ratio proposal and using the
standardized 'resolution: <number>dppx' instead.
- Discussed application of 'box-decoration-break' to bidi splits
====== Full minutes below ======
Present:
Glenn Adams (via IRC)
David Baron
Elika Etemad
Sylvain Galineau
Daniel Glazman
Arno Gourdol
Vincent Hardy
Koji Ishii
John Jansen
Brad Kemper
Chris Lilley
Peter Linss
Alex Mogilevsky
Edward O'Connor
Anton Prowse
Florian Rivoal
Alan Stearns
David Storey
Daniel Weck
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2012/01/25-css-irc
ScribeNick: vhardy
Administrative
--------------
glazou: we have a few extra items. The first one is about sending
the agenda to the public list instead of the WG. I would
like to give a few days to everyone to contribute.
glazou: if we reach consensus, we will start to send the agenda to
the public list starting from next week. If you hit reply,
the regrets would go to the public list, so be careful.
<tantek> glazou, +1 on sending the agenda to the public.
glazou: meal restrictions?
* ChrisL restricted to good food
* tantek is pescatarian (vegetarian + fish ok)
glazou: please send me the dietary restrictions before the F2F.
glazou: we will not be able to have food during the F2F in the meeting
room. there are restrictions about what can be done in the
meeting rooms.
<tantek> should we put a "food prefs" column on the f2f wiki page
table of attendees?
CSS2.1
------
glazou: I wanted to talk about the 2.1 issue. Anton posted a large
number of 2.1 issues recently. I saw a few questions on the
web about what we are doing about the errata.
glazou: Peter and I discussed it and we think it would be good to
work on it during the F2F to give a signal that the issues
remain on the radar. Opinions about that?
chris: I think it is good to show that 2.1 is not abandoned. It is
the basis for CSS3.
johnjansen: we resolved that Bert would make sure he would have all
the issues on the wiki.
anton: the majority are from the mailing list since the wiki page
was created. They are new issues. I am in the process of
moving the issues; there are about 30 of them.
<glazou> #antonp { speech-rate: slower; }
anton: the ones from Jan-April 2011 need to be reviewed. It was a
high volume feedback period and I want to make sure we cover
all.
anton: There are about 100 issues total that need to be taken care of.
<tantek> for CSS 2.1 issues, would it be possible to request that
people raising them add them directly to the wiki? e.g.
we could indicate that issues added to the wiki will
likely get attention first (which might provide sufficient
incentive for issue contributors to do so)
* plinss notes Anton clocked at .75 TimBLs
* sylvaing i'm pretty sure you need a license for that
anton: we will have 100 issues to take care of. I am trying to get
them on Bugzilla before the F2F. I may only have 75 total,
but I'll try to do all.
anton: should we have all of them in the errata. Some are easy, some
hard.
anton: this is the number I was expecting.
johnjansen: do you need help?
...
<tantek> vhardy, depends on the conclusion of the issue. Some issues
may not require a spec change but clearly still caused a
question to be asked so could use an answer on a wiki page
FAQ for example.
antonp: I have done the difficult mining on the mailing list. The
issue is to move the ones from the wiki. I could just copy
to Bugzilla. I am trying to write bug descriptions that are
understandable without having to read the whole thread.
johnjansen: we will have a large number of issues on Bugzilla and we
will talk about it at the F2F, so we will demonstrate
that we are focused and make progress.
glazou: yes.
johnjansen: I will be regrets for the F2F
glazou: will you be there?
antonp: yes
florian: as long as we schedule enough time to address significant
chunks, we do not need to address all of them at the F2F.
glazou: I agree. I plan to write a blog entry on w3.org to say we
are going to address the 2.1 issues during the F2f.
glazou: anything else?
(silence).
CSS Transform parsing rules
---------------------------
vhardy: request to move to a future meeting when Dirk can be here.
Media Features
--------------
<glazou> http://wiki.csswg.org/ideas/media-features
glazou: I would like everybody to review this so that it can be
discussed.
florian: it is fairly simply, there is a new feature for scripts.
If your browser supports javascript and has it turned on,
then you get 1, otherwise you get 0. Which is what you need
to turn on styles that need to apply when you do not have
script support.
florian: no support for fine-grained detection for situations where
some scripts are enabled and some not. There is a suggestion
in the proposal. It is kind of an edge case.
rossen: what is the prime use-case for this?
florian: because scripts may actually affect the style as they run.
florian: it is different when the script that were going to modify
the layout do not run. Currently, there is a javascript
library that addresses that, by removing classes when
scripts run. A declarative solution would be better.
sylvaing: so we would do what Modernizr does.
antonp: except in a less fine grained manner.
florian: to my question. We might be able to turn what I proposed
on its head and have a 'no-script' media feature instead
of a 'script' media feature.
florian: ... the problem with the script media feature is that i
a browser supports javascript but does not support this
media feature, then you will get the wrong style. If we
do 'no-style', you would not be worse of than today.
florian: if you have a media feature that is not supported in the
media query, the entire query is equivalent to not all.
florian: as an author, if you write script:0 rather than just script,
it does the fallback properly, so may be we do not need to
revert.
antonp: I wonder about the case where you turn off the script but
the media feature is supported.
florian: it works in that case.
dbaron: would script:0 lead to the same error handling as no-script ?
florian: what happens when the new media feature is not supported
should be least disturbing to the page.
florian: if you use it explicitly with a value, then either is fine.
Without an explicit value, no-script is better.
florian: if we want to add finer grain later, script() is a better option.
florian: harder with no-script.
florian: do we care to extend later on.
glazou: we are not going to discuss the whole feature right now.
florian: If people could think about it, that would help.
glazou: will discuss at the F2F if we get enough feedback.
GCPM Issues raised by Tab and fantasai
--------------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Jan/0895.html
fantasai: nothing major, just things Hakon needs to take care of.
(Hakon not on the call).
fantasai: as long as Hakon is tracking it, we are fine.
color tweaking
--------------
glazou: since the release of CSS 2, we got requests to do color
tweaking like lighter(). We refused so far, sometimes for
technical reasons, sometimes not. We need to come up with
an articulated technical answer.
chris: we originally said that filters could do that but Tab argued
back and I agreed. We are looking for a calc function.
chris: for lightness, additive is not going to be sufficient,
because you lose your colors. Some sort of hue rotate seems
useful functionality to me.
glazou: what do other people thinkg?
florian: I think it did not make sense to address before variables.
I think a big blocker has been removed.
glazou: I tend to agree with that.
glazou: I think variables will be immensly useful here.
glazou: how could we do that.
fantasai: until we have a concrete proposal, we are not going to make
progress on a telecon.
glazou: but do we want to dedicate time on that.
chris: yes, and we already have filter functions/equations that could
be reused here.
* fantasai thinks this belongs to css4-color or css5-color
ACTION: Chris to create a concrete proposal to address the color
tweaking requirement.
<trackbot> Created ACTION-417
<tantek> I'd like to see examples of real world web pages where
authors are currently doing color lightening/darkening
(by any method, CSS preprocessing, or in a javascript
function etc.) before committing to adding it to CSS.
<tantek> I'm not convinced it is something that is broadly necessary,
feels more like a "wouldn't it be cool if" type of feature
request.
<tantek> if there's an advocate for this feature, please capture it
as a theoretical request for css4-color on the wiki.
<sylvaing> I think this is something that makes sense once you have
variables
glazou: a lot of people have been asking for that at the Paris web
conference, they were all web authors.
<sylvaing> I even think it's a variable scenario, period
* ChrisL wonders why 5
<fantasai> because color-correction and #rrggbbaa seem a little more
baked, so might wind up shipping 4 before we have a concrete
spec for color math :)
glazou: anything else to discuss now?
<tantek> (until someone shows at least *some* real world attempts at
doing so, so far I have seen none in the emails)
<sylvaing> tantek, there is one on the list: designer defines a color
scheme for an entire design then wants to adjust it in one
place vs. overwriting each instance of a color value all
over the place
<bradk> Here is an example of a color tweaker on the Web that includes
tint and saturation variations of a base color:
http://www.colorsontheweb.com/colorwizard.asp
<tantek> sylvaing - I know the use-case, I just didn't see a page on
the web doing so. (URL?)
<sylvaing> tantek, why would you see it on a page? by the time the
page is out the color scheme has been tweaked
<tantek> bradk - I agree there are tools for doing so, now show me a
URL with tweaked colors where the author has used that tool
to do so
<tantek> sylvaing - I'm asking for examples of pages from authors
where they simply claim they've had to do such math (or
used a tool) beforehand
<tantek> with actual color values we can look at
<bradk> tantek - I think that would be hard to prove.
<sylvaing> tantek - i don't follow. you want me to provide a page
where the same color values are used multiple times?
<tantek> bradk - not asking for "proof", just for authors statement
thereof
<tantek> "this is a page I built by hand with tweaked colors,
example: color1, color2 which is a lighter/version of
color1" etc.
<sylvaing> tantek - the use-case is called css variables. easy color
tweaking by designers is a special case of that imo
* tantek wants real world examples so we can look at the *actual*
colors people have used and what they *claim* is the
transform (lighter/darker, other) that they've done by
hand or otherwise.
<tantek> sylvaing, css variables is not a "use-case" it's a solution.
* glazou notes that with the "real examples" requirement, we would
not have standardized a lot of stuff that proved to be useful
<sylvaing> tantek - fine; this is one css variables use-case
<bradk> tantek, that just seems extremely unlikely that a designer
would go into such detail about how he/she figured out the
colors that are all shades or saturation variations of each
other.
<tantek> glazou - note that I'm not saying "don't do it", I'm simply
saying I will classify this as a theoretical use-case until
someone provides real-world URLs of authors manually (or
through a script etc.) doing it.
<tantek> and theoretical use-case doesn't mean don't do it, it means
it gets lower priority than real-world use-cases / problems.
<sylvaing> tantek - you cannot find such a URL. all you can see is a
page after it's been tweaked.
<tantek> sylvaing - see above.
<sylvaing> tantek: ok, i don't get it.
<tantek> sylvaing, from above:
[17:36] tantek: bradk - not asking for "proof", just for authors
statement thereof
[17:37] tantek: "this is a page I built by hand with tweaked colors,
example: color1, color2 which is a lighter/version
of color1" etc.
<sylvaing> tantek, then give that answer to the authors on www-style
who ask for it?
<tantek> and you *could* find such a URL if there were a javascript
library that did lightening.
<glazou> tantek: will post a call for contributions on color tweaking
on my blog, with my co-chair hat on
<tantek> sylvaing, burden is on the feature requester.
<sylvaing> tantek i think doing this with JS is specifically a
non-goal for authors
<tantek> otherwise, I may get to it eventually with adding it to the
css4-color wiki page
<glazou> right
<sylvaing> tantek, anyway. we don't need to resolve this now and we're
adding noise to IRC
<tantek> sylvaing - not asking for pre-existing JS library as a
requirement, that's just one way of demonstrating an existing
real-world use-case
<tantek> saying it's a non-goal is not useful
<tantek> in general, if authors are using a JS library (or server-side
library, like SASS) to achieve some presentational effect,
then it may be a good candidate for consideration for a CSS
feature. but absence of such library does not prove anything,
so saying no such library would be expected to exist is also
not useful.
Media Queries: device-pixel-ratio
---------------------------------
florian: I wanted to ask something about media queries.
florian: device pixel ratio is a media feature. It exists in various
browsers (WK, Opera have it).
florian: that seems useful, we should add it to the next level of
media queries.
dbaron: I looked at the images draft, and I think there is a better
way to do it. The css3-images draft introducts the dppx
(dots per CSS px) unit. If you have that unit, you do not need a
new media query. All you do is use these ddpx units and query
on resolution.
florian: the primary usecase is when you are on a device with a px
that maps to many device pixels.
edward: the device pixel ratio was more explicit about that.
edward: I prefer the media query since it is already implemented.
fantasai: is it prefixed?
florian: yes.
fantasai: then, I do not see a reason to standardize it.
florian: if we standardize, we can drop prefixes.
fantasai: if we drop prefixes, we can just drop to 'resolution'.
florian: why not.
florian: I am a bit confused. Do we need to change anything about
how resolution is defined?
dbaron: no, I do not think so. Just use dppx with the resoulution.
fantasai: just make sure there is an example, that should be good.
florian: sure. For the next level of media queries, we just need an
example with that unit and we are good?
dbaron: I think so.
florian: I'll get feedback from Opera implementors. Seems like it
would work.
florain: that is all I had on this topic.
CSS3 Background: box-decoration-break and bidi
----------------------------------------------
fantasai: Background and borders issues from previous call.
<fantasai> CSS3 Background: Applying box-decoration-break to
bidi-induced splits
http://lists.w3.org/Archives/Public/www-style/2011May/0059.html (ISSUE-182)
dbaron: do we define precisely where the splits happen?
dbaron: I worry that different implementations may split in different
places and if borders show up, then we have issues.
fantasai: wouldn't you have the same issues even without the borders.
dbaron: with borders, you only see where the begining and end are.
You do not not see all the pieces.
dbaron: does box-decoration-break also affect that?
fantasai: yes.
dbaron: I am afraid of that. Implementations may put extra breaks in
that do not cause problems but are not necessary needed.
dbaron: may be they don't.
fantasai: how do we address your concerns.
dbaron: we need to specify what those bidi splits are and see if they
are interoperable.
fantasai: I think that should be a separate issue. If we decide it
does not apply, then it does not apply ever.
dbaron: if we go with does not apply, then fine. However, if they do
apply, then we need to address the issue.
fantasai: could we say that if two pieces of the same box are exactly
adjacent, then they should be treated as one box.
dbaron: this is scary. We would need to go rewrite our implementations
for something for which there is no demonstrated use cases.
fantasai: today, if there are two adjacent boxes, they are already
treated as a single piece.
dbaron: would that still be true if the breaks applied?
dbaron: I think you make a bunch of assumptions. I do not know it is
true that implementations merge boxes like you said.
fantasai: I did not say they should. They need to render as if.
dbaron: my position is that the breaks should not apply, but I am not
sure.
brad: what are the use cases?
dbaron: I want to know the use cases and what implementations do now.
fantasai: I do not think we have use cases, because I do not think you
would visually highlighting boxes are discontinous due to
bidi reordering. You would typically not decorate it. It
would look weird.
fantasai: the problem is not use cases. We have a feature that applies
to boxes that split and it is not defined what happens in
that case. We can say that it does not apply or that it
applies.
dbaron: I would like to know what implementations do and what the use
cases are.
fantasai: imo there is no use case to put decorations on boxes that
are split because of bidi reordering.
dbaron: I think that what implementations do now is probably what
people do not want. Right now they do apply box decoration
breaks to bidi splits.
dbaron: if you put border on an inline with bidi reordering, you will
see the effect, even if the boxes are contiguous. Should the
spec. say that, or should the spec. have bidi reordered boxes
with merges.
<tantek> fantasai - test case that demonstrates the situation you are
discussing / asking for clarification/definition on?
<tantek> URL?
<fantasai> tantek: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1309
florian: if we do not have a use case, and we do not seem to have one,
it seems better to leave this undefined.
dbaron: there are questions about whether people put borders on
inlines in the first place.
dbaron: ... and thus whether to bother with box-decoration-break at all
plinss: people do that, I have seen it.
brad: most people would not want a border between two words becase a
word goes in the opposite direction. We should say that in the
spec. and explains it does not apply.
fantasai: I am happy with florian's suggestion.
plinss: I think we need to specify it.
florian: we could start with undefined and then nail it down later.
florian: when we have use cases.
<glenn> adobe in-design arabic version supports this type of feature,
but proprietary format
glazou: any more comments?
(silence)
szilles: what is the conclusion?
szilles: I thought there was support for what florian was proposing.
brad: I think it should be defined. I do not think we should default
to whatever uas do.
fantasai: whatever you do, it looks weird.
szilles: at a minimum, there should be a comment saying that we are
looking for use cases.
szilles: brad, I think we should leave it undefined and say so, is
that it will drive people to come up with use cases if there
are any.
<dbaron>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cspan%20style%3D%22border%3A%201px%20solid%20black%3B-moz-background-inline-policy%3A%20each-box%3B%20background-image%3A%20url(https%3A%2F%2Ftwimg0-a.akamaihd.net%2Fprofile_images%2F1605345343%2Fdavid-2011-09-13-by-nitot-square_normal.jpg)%22%3E%26%23x5d0%3B%26%23x5d1%3B12%3C%2Fspan%3E
dbaron: the url I pasted, shows that there are two boxes in this case.
If we started to apply it, we would get bad results. May be
we need to resolve this problem.
dbaron: I think that getting it right for the bidi cases is going to
be hard implementation-wise.
florian: we do not want to rewrite all our code. I say we should not
define it until we have use cases. Until then, say it is
undefined.
brad: then we end up with incompatibility.
fantasai: yes, but it is a weird edge case.
<SteveZ> +1 for Florian's statement
florian: may be it is better to let implementations do different
things, and later consolidate on the best behavior.
dbaron: I think the use cases are the same as borders on inlines.
dbaron: some people probably want it to look like this.
dbaron: then people who write in arabic for example, may have these
use cases.
dbaron: if you want borders around the boxes instead of open borders
dbaron: The right behavior is obvious but hard to implement.
dbaron: we want the borders to close where the borders are physically
separated.
fantasai: we could give two options:
fantasai: close the borders when they are separated
fantasai: or treat bidi split as always slicing.
fantasai: an implementation would be conformant if it does slicing or
if it does the 'correct' behavior. If it cannot, it can
treat it as slice.
fantasai: then we can see how uas implement it.
glazou: we are not going to resolve this issue today.
florian: can we agree on the next step?
florian: given dbaron's feedback, I do not think we should define the
behavior until we are clear on the desired result.
<dbaron> I think we are clear on the desired result but it requires
defining a whole bunch of new things we don't have already,
and it's not clear to me whether it's worth doing that.
glazou: we should get back to this during the F2F.
<dbaron> I think this is a pretty classic example of the problem I
described in http://dbaron.org/log/20100531-specs
Meeting closed.
Received on Saturday, 28 January 2012 08:48:50 UTC