- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Mar 2015 17:32:57 -0400
- To: www-style@w3.org
Generalizing 'region-fragment'
------------------------------
- The 'continue' property received the most attention for
bikeshedding.
- One issue with 'continue' is that it is a verb when almost
all property names have been nouns or adjectives.
- Some people were inclined to return the name to
'fragmentation' but most of the group felt that would have
no context outside of the working group.
- It was suggested that there was likely vocabulary for this
concept and that users of programs like inDesign or
PhotoShop would likely have some suggestions.
- There was also clarification on the purpose of having these
properties defined outside the overflow context. It was agreed
thought they are similar, they're not the same and therefore
should be separate.
The 'all' Issue
---------------
- TabAtkins brought up that the current behavior of 'all' isn't
viewed as particularly accessible since it removes the :focus
outline on an element.
- Consensus was the old 'default' that was removed from the spec
would fix the problem.
- The spec authors will go back and see if there are any
reasons that 'default' was removed that need to be
addressed and re-introduce next week for formal resolution.
Mandating Some Cursor Formats
-----------------------------
- The Microsoft team will look into if Microsoft is open to
submitting .cur and .ico to the web consortium.
- RESOLVED: Add a note saying .ico and .cur are the standards and
they will be expected in new products. It's an
informative note. It will be up to the person writing
the note as to what exactly goes inside.
- There were no objections to mandating PNG as a supported format
of the <image> CSS value, as well as SVG if the implementation
supports SVG and saying for cursor that all non animated
formats supported for <image> MUST be supported in cursor, and
that all animated formats supported in <image> SHOULD be
supported in cursor. However, Microsoft asked for a week to
review, so formal resolution will be asked for on next week's
call.
Logical Overflow
----------------
- Most people seemed to agree that we should overflow the same way
we're doing other logical properties and whichever is declared
later wins the cascade, but conversation will continue on the
mailing list to suss out any added complications.
Underlining Spaces
------------------
- Work on trailing-spaces will be in CSS Text level 4
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Sanja Bonic
Bert Bos
Bo Campbell
Adenilson Cavalcanti
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Dael Jackson
Brian Kardell (IRC Only)
Toru Kawakubo
Brad Kemper
Peter Linss
Michael Miller
Shinyu Murakami
Florian Rivoal
Andrey Rybka
Simon Sapin
Lea Verou
Ian Vollick
Greg Whitworth
Steve Zilles
Regrets:
Tantek Çelik
Simon Pieters
Dirk Schulze
Mike Sherov
Alan Stearns
Scribe: dael
glazou: We have regrets from ChrisL, TabAtkins will be running
late, and possible regrets from tantek.
glazou: Anything to add to the agenda?
Florian: I'd like to add underlining spaces. Also, implementors
had three weeks to review box sizing. There's one week
left, but I haven't heard anything.
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Feb/0445.html
glazou: We'll add underlining spaces at the end of the agenda.
glazou: Anything else?
glazou: First on the agenda is mandating some cursor formats.
glazou: This will be difficult without ChrisL or tantek
Florian: Can we take this a bit later once we have TabAtkins?
glazou: Yes.
glazou: Next topic is the 'all' issue.
glazou: Is Cameron on? Probably not because of time.
glazou: Item 3 is removed from the agenda. Let's do #6
Generalizing 'region-fragment'
------------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0161.html
Florian: I sent a long e-mail a while ago dealing with fragments.
I won't re-summarize, but what's tricky is naming the
exact values.
Florian: This isn't a great topic for the call, but there hasn't
been much activity on the list. The idea is you have a
property that deals with fragmentation. One value means
don't fragment an overflow as usual. There's another
where if you overflow you do it clone yourself
Florian: Another is picking up the idea from Opera about
generating pages. Another is discarding a fragment break.
Florian: Another is go to the next region in the chain if there is
one.
Florian: So this general set is easy to define at a high level, bu
some values don't make sense in some contexts. For exampl
if you say go to the next region and you're not in a regio
chain, what does it mean? So they need to relate to eac
other. I'm trying to figure out what computes to what.
Florian: I've realized the initial meaning of 'auto' and the value
for go to the next region, 'next', are the exact same. I
don't think 'auto' is a great name for a computed valu
that has a specific, non magic behavior.
Florian: If we look at how things should be called, 'next' is a
good name for a computed value. In terms of initia
value 'auto' is a better name, but I had to pick one sinc
they are the same. I picked 'auto' because it's more
natural but I'm still a bit unhappy about the names.
Florian: This isn't just bikeshedding, but also what values we have
and how they compute into eachother. An alternative is
instead of having a 'next' value, we could have break
that goes to the next region or discards if there isn't
one and then we wouldn't need an explicit 'discard'.
Florian: But Fantasai didn't like that, and pointed out that
discarding should be more explicit. So discard is a
separate thing. But I'm not entirely happy with it so I'd
love more input and I'd like to find better values with
more appropriate names.
Florian: I don't think we can solve this during the call, but I
wanted to get awareness about there being an issue.
glazou: It was certainly worth the presentation
<dbaron> the current conclusion seems like the best of the options
presented so far
Rossen: Starting with the 'continue' property, it's fairly awkward.
Continue what? Continue the playback, the streaming of the
video, the layout?
Florian: My original proposal was to call it fragmentation which
makes more sense for spec people, but less for everyone
else.
Florian: I'm not ecstatic about the naming. I think 'continue'
is too vague and 'fragmentation' is too obscure. If you
have a better name, go for it.
Florian: What we have now can work, but it's not ideal.
<dbaron> 'continue' is awkward as a CSS property name since it's a
verb, whereas most property names are nouns. (I feel like
'continue-in' might be a little more specific, but it
still has that problem.)
Rossen: The way I've understood this is it's all about layout,
right? It's about layout and how the content inside an
element behaves when it crosses a fragmentation boundary.
Florian: There will be one value that doesn't cause it to be a
fragment container and all the others will with different
behaviors as to where the content after the break goes
There's just one value that says don't become a
fragmentainer.
Florian: How we call the property and what is the set of values,
what's in the spec is possible, but I'm not terribly
happy about how they're called.
Rossen: The previous, for me, naming consistency was a bit better.
When basically this spec piggy-backed the overflow
property. Making fragments or page, etc.
Florian: Overflow and fragmentation aren't the same. Fragmentation
is triggered by overflow a lot, but if you have text
shadow bleeding out it won't cause fragmentation.
Rossen: That's not true. In borders you can define what happens in
borders. So overflowing and fragmentation are tightly
coupled.
Florian: There are interactions, but you still want overflow
control separate from fragmentation control.
Rossen: So how do you have overflow: visible and overflow:
fragment?
Florian: What's the problem with that. If you have position
relative or text shadow it bleeds out of the content area.
This is what you get on an article today.
Rossen: You're talking about different things. You're talking
about monolithic things that don't fragment and whether or
not something fragments.
Florian: So the 'continue' prop determines if you're a
fragmentainer or not. If you are a fragmentainer, there
are still places that can have overflow. And where that
overflow occurs it's perfectly described by the overflow
property.
dbaron: The conceptual difference is overflow is painting and
fragmentation is layout. You can have overflow in thi
painting context. It does make sense to have two differen
things.
dbaron: I'm not crazy about 'continue'. The other problem is it's
a verb and most of our names are nouns or adjectives.
Florian: Unless we like the fragmentation name, this is the best
name we have.
BradK: I think fragmentation is a better name.
fantasai: No one outside the CSS WG knows what fragmentation is.
We want to use a name that authors would understand. So
how would they explain my content goes to another page
if it doesn't fit. If they have a vocabulary there,
great. If they don't we need to have a new name.
<leaverou> fantasai++
<smfr> spill-over:
<dbaron> Yeah, I agree that fragmentation is not a good name.
<BradK> It's not great, but 'continue' doesn't seem better
TabAtkins: Do we want to do a poll tomorrow?
glazou: Find what the PhotoShop users and inDesign users use. I'm
pretty sure this kind of thing exists and if we can re-use
that word.that would be good. It can be from outside CSS,
but if it's known we have to use that.
glazou: I suggest me move on. Is that okay?
Florian: Sure. I'm not looking for a solution during the call
I'm looking to raise awareness and get feedback on the ML.
The 'all' Issue
---------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0253.html
TabAtkins: The all property is a shorthand that resets everything
except the unicode bidi. This is a problem in a few
cases. The one brought up is 'all' kills the :focus
outline on an element. It's hard to put it back
manually because even if you use auto style it might
not give you the right color. I know on mac it's blue
or gray, but auto is always gray
TabAtkins: This is problem because accessibility. I'm not sure how
or if we can solve this. But it's difficult to tell
between a property for all states of an element and one
that applies to just the normal state. So it's the same
selector for focused and unfocused unless you go out of
your way.
<dbaron> all: initial; outline: unset;
<dbaron> er, no, I guess we'd want default, which we dropped
<fantasai> dbaron, that won't work
<fantasai> yeah
TabAtkins: I don't know how to fix this. Any suggestions would be
great. Maybe we can do something clever about
separating it out and it can go somewhere good with
'all'.
Florian: Maybe I'm naive about what 'all' is being used for, but
wouldn't they actually want to say reset to UA styles?
TabAtkins: Doesn't matter. You're still going to override the
focused value.
fantasai: Florian is correct. We have all: default which the
authors get what they want. If they're trying to reset
everything on their on they have to use a selector
that's more specific.
TabAtkins: That does not apply. all: default doesn't work here.
The selector that applies is usually :focus
fantasai: But specificity doesn't matter across levels.
glazou: Wait. We've got dbaron on the queue.
dbaron: I think some of these things are things that aren't where
people should use 'all'. I think people would want to use
'all' when you have an element you want to mostly
disappear in terms of default styles. So you want to rely
on a block with no styles is almost invisible. But you
probably don't want to apply 'all' to anything where you
want initial behaviors;
leaverou: I think that authors want to use this to reset all.
<leaverou> I don’t think so. I know it :) I recently tweeted about
it and got many replies along these lines.
dbaron: I don't think that would work.
TabAtkins: Neither of the things helps the default selector.
Florian: I was expecting default would be the thing in the UA
stylesheet for the same selector.
TabAtkins: It will run the selectors, but it won't find the :focus
rule. And because button: foo is more specific it will
over-ride the UA stylesheet.
fantasai: TabAtkins, you're making no sense.
dbaron: I think everyone disagrees with you about how default
works.
TabAtkins: Please explain.
dbaron: Default says this declaration overrides the other stuff in
this level of the cascade and causes it to fallback to
lower levels. So if you have all: default in the author
level, you fall back to the winner in the user level or UA
levels.
TabAtkins: I was thinking run the cascade with the user level and
whatever falls out at the author level.
fantasai: That's how we defined it.
TabAtkins: We hadn't defined it.
fantasai: We had it in the spec and removed it. What we had is
what dbaron explained.
TabAtkins: Okay. If that works, fine. Let's put it back in the
spec.
TabAtkins: Sound good?
dbaron: There were issues with default as to why we removed it. We
should look at what they were before we resolve to put it
back.
fantasai: We had implementors not see why it was useful and didn't
want to implement because it was hard.
TabAtkins: That's what I recall.
fantasai: So instead we created this keyword and they were happy
with that.
<dbaron> I'm fine with adding 'default' back
<leaverou> If we add default, this would also be useful on a
per-property level too
TabAtkins: We can see if there were further issues and resolve to
put it back next week.
TabAtkins: It sounds like a proper definition will solve the issue.
fantasai: We can do that tomorrow.
Mandating Some Cursor Formats
-----------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0199.html
glazou: There was some discussion on this and it's quite important.
As you probably all know the current only interoperable
options for cursor are .cur and .ico. They're
interoperably implemented and they're the defacto standard.
glazou: Unfortunately there is no open spec on them. There's a few
documents, but no open spec.
Florian: I think there's a fairly complete description on the blo
"The Old New Thing". But that is also not a spec.
glazou: First, my opinion is it would be really useful. If we
can't mandate without a spec, we should add a note saying
the two main implementations are .ico and .cur. Second, we
could mandate PNG and ChrisL, leaverou and I have been
campaigning for it.
Florian: On that, there were two things. One were to mandate PNG
and SVG if you support SVG. Elsewise we can say anything
used by <image> it must be support here. It would do the
same thing mostly with one level of indirection. So why
don't we do that and say in <image> we require PNG?
SimonSapin: Do we spec a format for background-image?
Florian: There are many places in specs where we don't specify
formats but where we can it would be useful.
fantasai: We don't specify formats anywhere in CSS, but we can put
a note this is what's used.
Florian: For images we don't because when they were new we
couldn't. Now pretty much everyone supports them. For
cursor there isn't interoperability, but there aren't the
issues we had 15 years ago with GIF and JPEG.
glazou: I agree with everything from both sides. tantek made it
clear you can't reference a non-open format. We haven't
before referenced a format, but SVG references PNG. So in
theory we shouldn't, but there is precedent. And not
mandating formats is why webfonts failed.
Bert: I think you said it on the ML, but why don't we ask
Microsoft to open the spec?
glazou: I was about to ask that and got interrupted.
glazou: Since we have Microsoft people on the call, I know you
cannot answer right now and you'll have to escalate this,
but these two formats are old and vigorously implemented.
It would be so good if you could submit them to the
consortium or open them.
Rossen: We'll have to go through some hoops, we'll take an action
item.
Action Rossen see about .cur and .ico
<trackbot> Created ACTION-676
SimonSapin: For these two formats, are there any patents or
intellectual property issues? Or are they just we
don't have a spec?
TabAtkins: I think they're old enough patents have expired.
Rossen: I don't they've expired. I don't believe there are
technical issues. I don't know if the people involved are
still with the company, but there should be documentation.
Rossen: We'll talk about it and get you back an answer.
Florian: I'd like to try and take a few directions. Originally go
with the note and add to the note with things from
Microsoft if we can. The other is if we can require PNG
and SVG.
glazou: I suggest asking if there's agreement or objections on go
with the note saying .ico and .cur are the standards and
they will be expected in new products. It's an informative
note.
dbaron: I'd also like to see images.
Florian: Of course.
glazou: No objections?
dbaron: No, but there's a bunch of variants of these formats where
we might have to discuss which we're referring to.
glazou: It will be up to the person writing the note as to what
exactly goes inside.
glazou: In principle do you agree.
TabAtkins: Yeah.
RESOLVED: Add a note saying .ico and .cur are the standards and
they will be expected in new products. It's an
informative note. It will be up to the person writing
the note as to what exactly goes inside.
* TabAtkins proposes using OUGHT for this
https://tools.ietf.org/html/rfc6919#section-4
* TabAtkins maybe WOULD PROBABLY
* fantasai is in favor of informative reference
* fantasai less certain about normative
glazou: Second thing, with PNG and SVG.
Florian: The way I think I'd like to go, #1 on the <image> value
type, there mandate PNG and if the implementation
supports SVG it must support SVG there. For the cursor
level, what it supports as static images in <image> i
must be supported for cursor, and any animated imag
format supported in <image> should be supported i
cursor.
Florian: That matches everyone but IE. Everybody supports al
their static image formats in cursor, and Safari als
supports the animated ones.
Florian: There are other ways to do it, but this makes sense to me.
glazou: It's the most beautiful approach, I agree.
TabAtkins: I'm fine with this.
glazou: Other comments?
glazou: Objections?
glazou: If you have a comment, please make it. This is a big
change in our history.
TabAtkins: HTML mandates a few formats.
Rossen: And an implementor can always not conform.
Florian: But if you have reason not to implement it's worth
hearing.
Rossen: I don't have any offhand reason before we take it up with
the people involved. It would be perhaps worth waiting on
this, even if it's a week, before we find out if we'll
have any hard reasons not to do it.
TabAtkins: So the thing you're possibly objecting to is the image
formats?
Rossen: Yes. But you can always not implement. That's why it's not
a hard objection, but also why I'm not completely agreeing.
If you give us a week we can have a more definitive answer.
<BradK> This means we can have a gradient as a cursor?
Florian: I can write the change and wait until you come back to u
before we apply it.
glazou: So there's no objection on the second item, but Microsoft
is asking for a week to review.
Rossen: Okay.
bcampbell: It appears to me that adding SVG as a cursor image it
might improve high contrast cursors. I would assume SVG
would scale better.
Florian: There's nothing preventing that.
Rossen: You were saying SVG will give you higher fidelity and
better a11y?
bcampbell: Yeah, I'm speculating. If you're in high contrast and
your cursor grows, I'm going to assume it will scale
better.
Rossen: I don't disagree on a technical level.
Rossen: I just need to talk to the people with law degrees.
<dbaron> was there about to be a resolution that got interrupted?
glazou: So no resolution, we'll revisit next week with Rossen's
input.
Logical Overflow
----------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0237.html
glazou: BradK, can you detail the proposal?
BradK: It was that we have a switch that allows overflow-x and -y
to turn into -inline and -stacking in terms of behavior,
but not in terms of computed values or anything like that.
It's just an effect. And we can call that property what we
want. Two values, one 'logical' and one 'physical'
fantasai: Other properties that have this kind of physical, we're
creating logical versions. So we should have overflow-
line and -block and it will be longhand.
<dbaron> I think fantasai said it would be reset by the 'overflow'
shorthand?
<glazou> but IRC did not capture it.
<Rossen> +1 to what fantasai said
Florian: There's two reasons people typically want this. One i
with borders, padding, margins... as Fantasai said. Th
other reason is if the fragmenting things we
discussed earlier are attached to overflow, they only
make sense in the block direction. So the longahnds being
physical is inconvenient. But since I don't think
overflow is a good home for the fragments, I don't think
that's a good point. So I'm all with fantasai.
<dbaron> Yeah, I agree with continuing the pattern we've been
using rather than using a different pattern for overflow
BradK: So even if the fragmenting stuff, you still want to know
what direction that overflow is in so you can set the
overflow in the opposite direction of block overflow.
Rossen: Can you elaborate on your use case? Why logical wouldn't
work as well?
BradK: In terms of the fragment being an on screen page.
BradK: Suppose the fragment creating new pages is in vertical
direction. You may have long lines you want to overflow:
auto probably.
Rossen: Can we take fragment off this? So we have one element with
a bunch of text and may have vertical flow.
Florian: I don't think we can take fragment off.
Rossen: You have have overflow on both sides if you have
monolithic elements.
BradK: Even if I have columns you might want vertical overflow to
be visible but horizontal overflow to use a scroll bar.
Rossen: We don't have that.
Florian: So if overflow-x or -y is not visible and the other on
is, the visible one computes to auto.
BradK: Ah, right
Florian: In general I think this idea of having cases where you
need overflow in inline and block directions is valid.
With the same priority we want to do the same thing on
overflow. The extra reason with fragments, I don't think
it applies anymore.
BradK: I think the more common way of having two things where we
have overflow: auto...you wouldn't know what way you're
going.
Rossen: If you're to specify logical properties it would work.
Florian: It wouldn't work now because we don't have logical
variance.
Rossen: But when we have that, which is coming in logical
properties spec, it would work.
<dbaron> So what are we still disagreeing on?
BradK: You would have an initial value that's based on the...not
the direction.
Rossen: It can be the logical one, not the physical one.
BradK: We could have two different initial values depending on
horizontal or vertical orientation.
<fantasai> If transforms weren't invented, I'd be suggesting we
make overflow-x/y and repeat-x/y logical and skip
having physical ones, but train left the station
already on that one.
dbaron: What is it you're proposing to have two different values?
Rossen: I don't think that's it. There's the proposal of logical
or physical
<dbaron> http://dev.w3.org/csswg/css-logical-props/
dbaron: I think most people, though maybe not everybody, agrees we
should overflow the same way we're doing other logical
properties. And whichever is declared later wins the
cascade.
<Florian> +1
BradK: I'm not totally opposed. It seemed like there were
complications, though. I'll put something on the mailing to
see if I can clarify my thoughts.
glazou: So I guess we'll move to the mailing list. We only have
two minutes remaining on the call. Anything we can discuss
in 2 min?
Florian: Transforms won't fit.
Underlining Spaces
------------------
Florian: There's the underlining spaces issue I asked to add.
fantasai pointed out the change we agreed to on text
decorations cannot go into level 3, it needs to be 4. I
think the entire property should be level 4. What do we
do about the initial value? Object or object together
with spaces or some kind of auto depending on how they
implement pre-wrap?
fantasai: I think that's more than 2 minutes of topic.
Florian: Probably. I just wanted to bring it up for awareness.
fantasai: I think the short one is #3 on the Agenda.
Florian: That was solved.
glazou: So there is removing the property to level 4. Given that
it's at risk and there's no implementations it could be
moved.
fantasai: What I've heard is Apple implemented at least one value
as how they handle default. So we might need to use it.
Also how the behavior of underline is handled is in that
level. And we don't have a complete publishable level 4.
If we're getting to wrap up 3 and have a solid 4, that's
fine, but it's not quite ready to be kicked out.
Florian: I just don't like two levels defining the same thing
differently, especially when there's no implementation
and even more so if the initial value ends up different.
fantasai: I'd rather we figure out what we want it to be in level
4 and have that idea and then move it down. The ideas
you have, you have a property but it's not very solid
and until it's solid I don't want to merge it in.
Florian: So you thinking of trying to define it in level 4 and
once it's solid we move it?
fantasai: If we end up with the solution that changes the original
values we can deal with it then.
Florian: Okay. Whatever we do we can do it in level 4 for now.
glazou: And that closes our conversation for today. Thank you very
much.
Received on Wednesday, 18 March 2015 21:33:25 UTC