- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 Dec 2014 20:42:37 -0500
- To: www-style@w3.org
Animations
----------
- RESOLVED: In level 1 we describe the current behavior of
findRule and deleteRule
- RESOLVED: Make appendRule always add at the end of the keyframe
no matter if the key already exists.
- RESOLVED: No change for now for Should CSSKeyframesRule inherit
from CSSGroupingRule bug
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=25670).
Media Queries
-------------
- There was a broad discussion about features that improve
accessibility that should become a part of Media Queries both
for their accessibility value, but also because they can have
value to designers in general.
- RESOLVED: Review all accessibility related issues to come up
with a broad proposal.
- RESOLVED: Reject scroll-position Media Query
- RESOLVED: The media features overflow-inline and overflow-block
are fine as they are. No change for current concerns.
===== FULL MINUTES BELOW ======
Scribe: dael
Animations
==========
glazou: Let's start again
glazou: sylvaing are you on?
sylvaing: I am.
glazou: Since you're on the call, I suggest we do Animations.
findRule with multiple indexes
------------------------------
sylvaing: Let me paste the issue.
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14788
sylvaing: The question was... We have 3 issues left. In this one
if you do a findRule can you use a comma separated list.
Today the answer is not really. Most browsers don't.
sylvaing: You need to be able to do it. Some rules will be comma
separated. So, if a rule is 25%, 40% there is no notion
of if you want the findRule for each. You'll only get a
rule that has both keys. It attempts to match the whole
string.
sylvaing: The original question was if you can get more than one
rule by patching in multiple values.
glazou: My problem with finding only one complete key is that you
need to have access to all the keys and parse them for
individual values if you have two inside a key. That will
be tricky for Animations editors.
glazou: I'd rather have findRule work on individual keys. That
leaves an issue for deleteRule.
sylvaing: Right now...it's not super hard, it is extra work.
sylvaing: The bigger question is if you...you want multiple rules
to come back, right?
sylvaing: Meaning you don't expect just the selector to be
separate items. You expect to be able to delete/find
more than one. That's a bigger challenge.
glazou: Everything comes from that we want to delete a rule. The
old works on indexes. The new OM there is a way to delete
based on a rule itself.
TabAtkins: I don't know.
glazou: It was a suggestion. That way you can find the rule, check
if it's made of the individual key, and then either delete
or change the individual key you found.
glazou: That's simpler. Different, but better.
sylvaing: Right now you find/delete by selector and it's not super
friendly.
TabAtkins: I kinda propose we figure out the reasonable,
compatible behavior, spec that, say it's deprecated,
and make methods that don't suck.
glazou: I agree if browsers will implement.
sylvaing: There's an intermediate possibility. You can add the
ability to get a list of all the keys. You can get them
all and do find, find, find.
sylvaing: The other rule...never mind.
glazou: You still need to browse the keyframes, split from the
comma, and trim. We could add that.
TabAtkins: Yes.
glazou: So that's getKeys on the keyframes rule.
TabAtkins: Or have a forward attr.
sylvaing: You have that with CSS Rules
TabAtkins: We could have a separate one that gives you a list or
array and make the existing one a put forwards of that.
<glazou> DOMTokenList ?
sylvaing: So saying you have a rule 25%, 50% and you get did key.
Now if you do delete 25%: do we fail or do we succeed
and it's there with only 50%?
glazou: I suggest the second.
sylvaing: I wondered about browser vendors.
TabAtkins: That's what I'd want.
glazou: If we don't spec it that way, authors will do it themselves
sylvaing: There's a bunch of issues. If you have a selector with
multiple values, if you can delete with only one value,
you should be able to find the same way.
sylvaing: You'd have to give findRule(25%, 50%) to get it. I think
we should find it with just 25%. Once we go down the
road of providing all the keys as an array and giving
people access to rules, we get to a point of redoing the
API.
TabAtkins: That's what I said.
glazou: But deprecating doesn't work and these things will stick
forever and be used forever. Deprecate is only in our
vocabulary, not in the users' vocabulary.
TabAtkins: People respond to deprecation when writing tutorials.
They don't do it with copy/paste code. That's why it's
not remove.
florian: It means we have a better thing to use.
glazou: If we deprecate findRule, what will be the name?
TabAtkins: findRules
TabAtkins: or find-Rule
dbaron: I think we want them more different. I'm also happy with
just documenting what they do and design better.
glazou: Okay. Is everyone okay with that strategy?
shans: So will someone work out with the browsers?
glazou: So there's two steps.
glazou: sylvaing will you document existing behavior?
sylvaing: Yeah.
glazou: What about the second? The next version that's better?
sylvaing: To be clear, the first step is describing existing
behavior in level 1 and doing better in level 2 or
something else?
glazou: What you said.
sylvaing: Can we resolve in level 1 we describe the current
behavior?
dino: And we hope the browsers are doing it the same. Even if we
document this we hope someone will change. I don't know if
they are.
gregwhitworth: I think that lets us know where our issues are.
glazou: Will you make a note that it will change?
sylvaing: Yeah, I think we decided to do that last week.
glazou: I can help.
TabAtkins: I can help too.
RESOLVED: In level 1 we describe the current behavior of findRule
and deleteRule
appendRule and Existing Keys
----------------------------
sylvaing: The next one....
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25035
sylvaing: The question here is, if we append a rule with an
existing key, what should happen?
TabAtkins: Can you just append it..it goes to the end?
sylvaing: I think glazou thought it would update the existing, but
we can redo that. Have more than one rule with the key
and append at the end, re-cascade and re-compute.
sylvaing: This one is for clarification. I think to follow the
existing API it just adds at the bottom. I believe
that's what browsers do.
glazou: To be clear, I have no preference, I just want it defined.
sylvaing: Yeah.
sylvaing: So any objections to making appendRule always add at the
end of the keyframe, no matter if the key is existing?
TabAtkins: As long as that's consistent with implementations.
RESOLVED: Make appendRule always add at the end of the keyframe no
matter if the key already exists.
CSSKeyframesRule inheriting from CSSGroupingRule
------------------------------------------------
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25670
sylvaing: Last one is about making the CSS keyframes rule inherit
from the grouping rule. It sounds like yes for the next
version from the discussion we've had.
TabAtkins: I'm fine with making the change in spec now, but I'm
not really bothered about it.
sylvaing: I can't imagine it would bug anyone. Would it?
dbaron: One issue is they both have a deleteRule method.
sylvaing: Ah yes. It wouldn't be so clear. Once we inherit we're
changing the API. I think it's good to move to the next
version.
dbaron: I don't know if that will be web compatible.
sylvaing: CSSGroupingRule is recent.
dbaron: The problem would be changing keyframes rule's deleteRule
method.
* smfr deleteRule(DOMString key); vs deleteRule (unsigned long
index);
sylvaing: I'm hearing this won't happen for a little while?
glazou: Everyone agrees?
RESOLVED: No change for now for Should CSSKeyframesRule inherit
from CSSGroupingRule bug
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=25670).
Miscellaneous
-------------
sylvaing: Then we have resolution on all issues.
sylvaing: Next step is I'll edit this week and then there's the
one from Sophia that I need you all to figure out. Once
that's done we can do LC.
glazou: Is that all for animations?
sylvaing: That was the only 3 issues left.
glazou: There was a bullet on the wiki about Animations level 4.
dino: That was to discuss the proposal. That's about additive and
cumulative Animation. Maybe do that tomorrow for Brian?
glazou: Can you attend tomorrow sylvaing?
sylvaing: 11am to 3pm is good.
dino: There's a bunch of scrolling stuff. Even if that's
Animations we can wait for Brian.
??: Theres a bunch of other people who want to attend.
dino: It would go for more than an hour.
glazou: Tomorrow at 11am?
dino: We break at 1 tomorrow?
glazou: Yes. sylvaing good for you?
sylvaing: Yes.
dbaron: Does that overlap AC?
glazou: I don't think so.
glazou: We have a problem. AC meeting is between 11 and 3. It
means a bunch of people won't be here.
sylvaing: That's okay. There may be background noise at a
different time. Afternoon is better for me.
dino: The new animation suggestion is not level 1.
sylvaing: If you think it can happen, it can. It can happen...I
can do it before 11, but there will be noise.
dino: And do you want to listen into scrolling stuff? I'm sure
dbaron does.
TabAtkins: Can you link your e-mails on the wiki?
dino: Yes.
glazou: So tomorrow.
glazou: Probably discuss this after 3. After the AC meeting.
glazou: That closes Animation.
glazou: Can we do layout this afternoon and MQ now?
Media Queries
=============
a11y queries
------------
florian: First item has been discussed before, but not concluded.
florian: One is Microsoft high contrast extension. The other is
ink saving mode while printing.
florian: Both inform about an intent. There is a request from the
user. It doesn't just indicate a request, it indicates
that something has been done to the page.
florian: I think in general the right thing to do is nothing.
Browser has adjusted. Sometimes the author can say I know
how to respond. You need to be aware the user has
requested and have to be able to say that the browser
shouldn't do its thing, I have magic to do.
florian: This property lets you say don't do the magic, I have a
better solution.
florian: Microsoft has high-contrast with 'auto' and 'none'. If
you say 'none' you can do your thing.
glazou: So the UA can override platform settings.
smfr: I don't think that's doable on all.
TabAtkins: It's per type of feature.
florian: There's another discussion about type of high contrast.
This is the thing that modifies.
jcraig: I think you're thinking about the old increase contrast.
On iOS8 and OSX10 there's things that allow changes of
colors. It's a lot more subtle.
florian: Microsoft's is more subtle.
jcraig: Sorry, I meant "subtle" in that OS X and iOS settings
"increase" contrast by more subtle amounts, while
Microsoft's rendering change most colors to 100% black or
100% white.
florian: Even though you know the UA is adjusting to make higher
contrast, you don't know how. The only way to respond is
do nothing or turn off auto adjustment. Trying to overlay
won't work nicely.
jcraig: We have some idea. I'm not saying it's a bad idea, but
they need to be extending to account for more platform
differences. Or reconciled so we can check on user
background/foreground colors.
jcraig: I like the "don't adjust for this value" proposal, but I
think it should be property level: e.g. don't remove
background-image.
florian: You want to do specific properties?
jcraig: I was thinking more specific things. That's the major
problem with Microsoft's where it removed background
images and we've seem a lot of problems.
TabAtkins: I was talking with James about OSX10's accessibility
and it's impressive.
TabAtkins: I think we should basically find the union of these
things, more or less. It's not huge, and spec a big
block of a11y media queries. Some are 'I'm requesting
something', some of them are 'I'm doing something to
you'. Some of them are a per-element, others are pixel
level.
TabAtkins: I think we should sit down with these and set some
meaningful conventions. We should then come to the
group with a solid proposal in a month.
florian: And if you do this at property level saying 'I've done
this to you', do we still want a property to disable that.
TabAtkins: Generally you'll need one to disable the adjustment.
Mac has one to adjust to 'not quite as white'.
TabAtkins: So it's hard to hit everything there.
florian: So you're agreeing with the general intention, but want
something more specific.
TabAtkins: And I want to spend time with a systematic proposal.
jcraig: We have reduce motion setting, a setting to turn off
transparency, and a "differentiate without color" setting.
These are things we wouldn't override mechanically in the
UA, but if a page author can adjust for a preferred
rendering, they should be able to detect that preference.
jcraig: Some of the others are....increased contrast and that's
more of a preference to allow the web page to know the
user prefers that.
TabAtkins: There's enough things around that I want to spend some
time on this, but your direction is the right way.
TabAtkins: Do people think it's okay to spend time on this?
fantasai: I think looking at everything together is a good idea.
florian: The one problem is these are a11y only instead of being
general features as well as general use.
glazou: On some mobiles you have power saving mode. My comment
earlier was if the user settings on the mobile say power
saving and the style sheet can override that, that's an
issue.
glazou: It's contrary to what the user wants.
TabAtkins: If it's at pixel level you can't override. If it isn't,
apps today can respond or not. An app can do it so I
think it's reasonable.
florian: There's a dangerous aspect. You could have someone just
make the screen blink because they hate animation
reduction.
jcraig: There will always be people that use things maliciously;
thankfully most people don't. We've found when we added
features to the accessibility sections, they gained
popularity in the mainstream user base, so over time we
moved them out of the a11y-specific section (for example,
bold fonts and large text). A power-saving mode could also
change the reduce motion MF or the washed or dimmed MF.
They're not all accessibility-specific. There's overlap.
jcraig: You can make them specific to the feature and they get
used more widely.
TabAtkins: I think a lot can be cast in a more general way than
pure a11y. They may not be super general, but okay.
florian: I think that's cool.
glazou: The proposal was to review all a11y features.
florian: And the intent is something along what I proposed earlier.
RESOLVED: Review all a11y related issues to come up with a broad
proposal.
scroll-position
---------------
florian: Another topic, there was a request for a scroll-position
Media Query and I don't think we can do that because it's
layout specific.
florian: It's clearly interesting to do things style-related, but
I don't believe Media Queries is the right mechanism.
TabAtkins: I think the right one is attached to the animation
behavior dino was talking about.
florian: Yes. I'd like to resolve to reject that.
TabAtkins: Even if you said selector, the same objection would
apply. Like a media class.
RESOLVED: Reject scroll-position Media Query
overflow-type queries
---------------------
florian: We have a couple things about overflow-inline and
overflow-block. We're trying to break the types into
essential features. One type about print is that you're
on a page. Inline-direction and block-direction tends to
be different
florian: A printer will page in the block direction. But there are
times it will go the other way. But before that we had a
question about what is it you overflow in this context.
florian: We concluded that what it was is the ICB if you're in a
scroll and the paged media if you're in paged media.
There's no word for either of these. Is this the right
object and, if so, what's it called?
TabAtkins: So naming suggestions for something more generic than
ICB or paged area.
fantasai: Wait...what?
TabAtkins: The thing that when you overflow causes pages to wrap.
On printed it's the page area. You'll overflow to new
pages.
fantasai: So on the first page, they're the same.
fantasai: You're a MQ so you don't know what page you're on.
TabAtkins: This is the general strategy.
fantasai: I'm having a hard time because I don't have context.
TabAtkins: We need a name for the thing that when you're larger
than it, causes overflow.
Bert: Is it fragmentainer?
Rossen: No. Not necessarily.
fantasai: Send me a link to the paragraph where you need this term.
<smfr> http://dev.w3.org/csswg/mediaqueries-4/#mf-overflow-block
<TabAtkins> http://dev.w3.org/csswg/mediaqueries/#mf-overflow-block
florian: Away from naming and back to what it is.
florian: When you overflow that thing in inline and block
direction, it causes different things.
florian: If you think of a matrix printer if you overflow inline.
Or a unix terminal. They all have variations. The set of
values that represent what can happen in inline is
different than the block direction
florian: If you overflow in inline you scroll or clip. There's a
case for tiling too.
florian: To be able to do the tiling, you need to know where the
pages are physically. That only happens in the inline
direction. Maybe also in block. Inline doesn't have
regular paging.
florian: Regular pagination can't happen in inline.
florian: Given that they're different, it brings us to having two
names.
florian: If you change the block direction in your stylesheet, the
meaning of the two inverts. Either you need to do a
special thing where you resolve the writing mode in this
MQ, or you put the same set of values on both axises.
fantasai: Another option...if you have a thing you can turn like a
piece of paper you can turn it.
florian: I think you've made this argument before, but can you
expand?
fantasai: If you have a thing that's turnable, you can say the
overflow block is paged etc. and if the author makes a
document that changes the writing mode, you turn it so
that page/screen is landscape and keep the same behavior
fantasai: For writing mode when you change it you want to do it
anyways. You'll want to be paging in the block direction
florian: A receipt printer scrolls until you ask for a cut. You
can't turn because it only prints in one way. The page
can't turn.
fantasai: If the root element is set to be vertical and it's sent
to a receipt printer, you want vertical in the short
dimension.
florian: And once it's printed you turn it.
fantasai: That's the way screens behave. If you set vertical, the
block scrolling goes off the screen. For paging also we
will define page in the block direction for the root.
Rossen: I think it's still worth figuring out when do you tile and
not.
florian: Since it's a MQ, it's not telling the UA to do anything,
it's just figuring out what it is. If it's tiling you
don't lose content, if it's clipped you lose content.
astearns: One of your options was have the same options in both. I
think when dauwhe brought up an issue about a table...
florian: I don't think it would be the same. You need to know how
the pages will layout next to each other and that's not
regular pagination. It's pagination-ish, but not the same
dauwhe: I'm not convinced there isn't a requirement for pagination
in the inline direction. We have books with massive
foldouts. You have a range of content going out to the side
florian: There's a few sets where it's straightforward and we
should have values for those now. The types we need to
handle a case like that needs two axises.
fantasai: We have the concept of spreads and that needs to get
into CSS.
florian: I agree and this needs to respond once we figure out
spreads.
fantasai: It might be you have to tile two pages.
florian: Is it tiling, is it a big page...?
TabAtkins: This is why we don't want to address it yet.
florian: I don't think this is incompatible with the end result
for spreads, but if you disagree that's fine.
SteveZ: I'm confused by dauwhe's example. I need a clear example
between pagination and tiling. Pagination to me is
dependent on how much fits in the block. To me tiling is
taking whatever is in the overflow direction and
generating pages to hold that.
SteveZ: There's two ways to do that. There's what you want for
tables which is layout in a bigger space and chop it into
chunks. A second way would be I don't do that for
overflows and I re-paginate the content in the overflow. I
don't know how that would create a usable result.
dauwhe: I was thinking of a case with hundreds of digits of pi
where you want to maintain it.
fantasai: You don't want to slice the middle of the word.
florian: There's where do you cut and what do you do with the bit
that has been cut.
SteveZ: So its already laid out, you're just picking out a chunk.
florian: So, with tiling the bit you're picking out would want to
appear in a specific place.
fantasai: For pagination you have a centered block, it should be
centered on the next page.
florian: But that's because that's how you styled it.
Bert: Think of a float, it has the same width on both pages if
they both have the same width.
astearns: The distinction is pagination finds a break opportunity.
In inline it could be a character boundary. That's what
makes it sound paginated to me.
fantasai: The layout of the contents creates the division. For
tiling nothing changes and you just have a bigger thing.
florian: And you may want to be smart about where you slice.
fantasai: You don't want to cut tables. You really want to cut at
a column. Tiling is we ran out of room and if you tape
these things together it looks right.
SteveZ: Is this like a spread case where you need to be more
specific in how you handle it? I don't think we have
anything written about this.
fantasai: We have things that clip and scroll in the inline
direction. Tiling might be an option, but it's not
implemented and so we should work on how it fits into
spreads.
florian: So as we expand pagination specs you can then use this MQ
and extend it to match the different modes. Right now
inline has clip and scroll.
florian: That's where I propose to start. Thank you for helping me
understand the rotation. I think we need to figure out
the name, but the spec can stay as-is elsewise.
dauwhe: One terminology question. Since one of the overflows uses
-x, -y, do we want to have that?
florian: We're conflating two issues. If it's -x you're saying do
the block direction. I think for this we can ignore, but
for overflow-x/-y I think it's unfortunate.
fantasai: I think they're physical. I think we're stuck.
florian: Are they still used?
Bert: Yes. They've been used a long time.
fantasai: (We also have repeat-x and repeat-y.)
florian: Other than the terminology, do we want to keep the spec
as-is?
fantasai: That seems to be where we're at.
dauwhe: I'm fine with terminology as-is.
florian: Now we says overflows the initial containing block and it
should add or the paged area if you have one?
dauwhe: We've used all the good words.
TabAtkins: Initial page-taining block.
fantasai: I'm not sure about the problem, so I can take a look.
florian: If you're in a paged thing, the initial containing block
isn't the paged area.
fantasai: It is.
TabAtkins: If your paged size changes in the document.
florian: Ignore me.
RESOLVED: The media features overflow-inline and overflow-block
are fine as they are. No change.
Custom Media Queries
--------------------
florian: So we have custom media queries. Do you want that one
TabAtkins?
TabAtkins: I don't recall what we need to do except I need to
finish the spec.
florian: We can discuss what's called issue 4.
<florian> http://dev.w3.org/csswg/mediaqueries4/#script-custom-mq
TabAtkins: This would be easier if the spec was on the screen.
TabAtkins: Ignore that some of those use underscores, we changed
that.
TabAtkins: We already discussed custom media queries being aliased.
If you want custom MQ that aren't aliases, I was looking
at an API like this.
TabAtkins: You have a custom media query that's a map and you set
the value. Current plan is it's a number or it's one or
more strings that have to match the ident production.
TabAtkins: I don't have a good way to talk about units in here. If
we pretend it has a length, you have to assume the 5 is
pixels. When we have the better OM eventually we can
have it take those and all the links will be
interoperable, but for now I think it should be int and
they document what it refers to with the assumption
we'll make it better.
TabAtkins: This has been up for a while, but if there are comments
that would be good.
* fantasai wishes custom things didn't require double hyphens
* fantasai thinks they look awkward
* fantasai -this- looks less awkward
Bert: I don't understand the order they're evaluated. In this case
I assume script first because foo isn't defined.
TabAtkins: foo is false and when it has a value it works.
florian: You just have to be careful to define the difference
between false and syntax error
Bert: So you can have a media attr on a link element: that cannot
include the script?
TabAtkins: Links can have a media and you should have that work
here. Scripts always run.
TabAtkins: MQ on elements, picture in particular, are used by the
preloader and that would never be usable by this.
TabAtkins: I'd like a solution that lets us define this in a way
that's preloader friendly. That would define a custom
MQ that you could use in stylesheet, but also for page
where the preloader could figure out what is going on.
TabAtkins: Right now you have to repeat yourself over and over
again. I'd rather a nice way to make those rely on a
single point so there's less editing badness.
TabAtkins: I will want to do something with that in the future.
plinss: Is the custom media scoped to the stylesheet?
TabAtkins: Yes.
??: What if you have MQ for bar and you haven't set it and you do
later. Are we dropping it?
TabAtkins: Unknown MQ evaluate to false. That's in the spec. It
doesn't drop the entire MQ.
SteveZ: Did you say this is only scripts?
TabAtkins: No.
glazou: CSS is a global object. That means CSS gets the media set
by one document. That seems wrong.
TabAtkins: We've run into that before where namespace is on window
not document. Maybe we put CSS namespacing on an object.
zcorpan: That CSS is on window doesn't mean it effects them all.
TabAtkins: All things see the window
dbaron: Lots of things are effected. The spec calls the consistent
thing a window proxy.
TabAtkins: This is all confusing. If it's sufficient to say only
the primary document needs to know about this and
saying this kind of stuff only applies to the document,
I'm fine with that.
florian: And I think we're done with MQ.
glazou: So we can find another topic now, or go to lunch now.
[lunch break]
glazou: We start again in an hour.
florian: TabAtkins and I have a few edits that don't need
discussion now, but once we do we'll be ready for a new
publication.
Received on Thursday, 18 December 2014 01:43:06 UTC