- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 24 Sep 2015 06:59:59 -0400
- To: www-style@w3.org
'resize' on Replaced Elements
-----------------------------
- RESOLVED: Extend 'resize' to <img>, <object>, <iframe>,
<canvas>, <video>, <svg> in level 4.
- RESOLVED: Add normative prose in level 3 that a UI may extend
'resize' as described for level 4.
Implementability of Computed Value Rules for align/justify-self/items
---------------------------------------------------------------------
- This topic is better suited to the mailing list.
Houdini at TPAC
---------------
- Anyone involved in Houdini was asked to put their name on the
wiki saying if they are available to attend a meeting at TPAC
and, if so, what days they would be available.
Computed Value for text-orientation: sideways or sideways-right
---------------------------------------------------------------
- RESOLVED: Describe 'sideways' as what 'sideways-right' used to
do. State that for legacy compat UA may support
'sideways-right' value that does the same thing and
computes to 'sideways'.
Float Pushed to Next Fragmentainer, What About Siblings?
--------------------------------------------------------
- RESOLVED: Moving a float to the next fragmentainer does not move
in-flow content that comes after the float. (However,
per CSS2.1, subsequent floats do move down.)
Clarification Proposal for Border Colors
----------------------------------------
- RESOLVED: Clarify in level 3 you can't make it solid black.
Control Characters
------------------
- The group needs to hear from TabAtkins about Chrome's current
timeline for the change in control characters.
- Depending on what TabAtkins says, if some browsers are still
planning on releasing the change in December, the publicity
campaign for this breaking change needs to begin ASAP for the
web developers to have time to react.
CSSWG Twitter Account
---------------------
- The account will continue to be shared in the same way for now.
Publications
------------
- Spec authors were reminded that they need to post notifications
to www-style when their spec is published. Full publication
rules are here: http://wiki.csswg.org/spec/publish
===== FULL MINUTES BELOW ======
Present:
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Alex Critchfield
Greg Davis
Elika Etemad
Daniel Glazman
Tony Graham
Koji Ishii
Dael Jackson
Peter Linss
Myles Maxfield
Florian Rivoal
Simon Sapin
Hyojin Song
Alan Stearns
Greg Whitworth
Regrets:
Rossen Atanassov
Adenilson Cavalcanti
Simon Fraser
Michael Miller
Edward O'Connor
Anton Prowse
Hiroshi Sakakibara
scribe: dael
glazou: Let's start
glazou: First thing, gregwhitworth I saw your request, but as you
said it came in late so maybe it's good to let people
review.
gregwhitworth: Sure.
glazou: I'll make sure this is added to next week.
gregwhitworth: Okay.
glazou: Any other additions?
'resize' on Replaced Elements
-----------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Aug/0333.html
glazou: fantasai, are you on?
glazou: No. Can someone cover this?
Florian: For the moment 'resize' only applies to elements that
have overflow of something other than visible. Applying
it on images or videos makes sense, on iframes too, so
the proposal is to make it apply to replaced elements.
There might be difficulties for form elements, for things
like a button it may be less useful.
Florian: It might even be harmful on very small form elements like
a checkbox where the UI for the browser could be as large
as the control and it messes up the interaction.
Florian: Probably no one is trying this on the web, but there is
mild compat concern. Generally it makes sense to me.
* fantasai thanks Florian for handling this issue, probably he's
more qualified anyway
glazou: You said you wanted to extend to replaced elements and you
mentioned elements that are not replaced.
Florian: Did I?
glazou: Some of the form elements you mentioned were ones that are
not replaced.
Florian: Some are and some aren't, maybe I'm wrong on which.
glazou: Checkboxes are not.
Florian: Okay, that helps. I think we have a list somewhere.
glazou: I'm not sure we do.
dbaron: I don't think we have agreement on what is replaced.
Florian: In general if it just applies on something not useful but
not harmful I don't see a problem. But if it would apply
to things on which the 'resize' handle would disturb the
interaction it's bad.
glazou: I'd be happy to see 'resize' apply to images, videos and
iframes.
Florian: So maybe we make it explicit for those three.
* fantasai is in favor
glazou: Implementors? fantasai said +1
myles: It's fine to me.
<gregdavis> +1
glazou: Other opinions?
gregwhitworth: I'd prefer a whitelist where we add those three
where the use case makes sense.
Florian: Yeah, maybe. It might be okay with replaced elements, but
without a list it's difficult to check.
gregwhitworth: I'm okay with iframes, images and videos. Yeah.
glazou: What about canvas?
fantasai: It's an image, right?
Florian: Yeah...
glazou: Resizing the canvas could effect the zoom factor when you
draw inside.
fantasai: Still...then don't set it on a thing that can't be
resized.
Florian: I don't expect there are a lot of style sheets trying to
apply resize to a canvas that's not resizable.
glazou: There's consensus to add images, videos, and iframes to
resize. is that reasonable to everyone?
<TabAtkins> Oh yeah, sorry, +1 from Chrome on adding resize to
replaced elements.
<TabAtkins> Resizing canvas is fine. It just scales it via CSS, no
problem.
<fantasai> <img>, <object>, <iframe>, <canvas>
<TabAtkins> <video>
<TabAtkins> Oh, and <svg>!
Florian: These elements, or these type of things?
glazou: That's the point I was making.
fantasai: It should be the types of things that go into these tags.
glazou: TabAtkins is right because there's SVG images. It's not
just the <img> tag.
fantasai: We can list the tags and state a replaced element is
this type of element and if it's introduced some other
way it qualifies.
glazou: Any objections to that?
RESOLVED: Extend 'resize' to <img>, <object>, <iframe>, <canvas>,
<video>, <svg> in level 4
glazou: Who will do it?
Florian: I will for 4.
fantasai: We might want to put in 3 that a UI may do it.
glazou: Shall we resolve we need a note in level 3 that a UI may
extend resize in level 4.
Florian: I'd do it as normative prose.
glazou: Okay.
glazou: Other opinions, objections?
RESOLVED: Add normative prose in level 3 that a UI may extend
'resize' as described for level 4
Implementability of Computed Value Rules for align/justify-self/items
---------------------------------------------------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Sep/0099.html
glazou: dbaron this is yours.
dbaron: Do we think this is useful to discuss on the telecon?
glazou: It was leftover from last week.
glazou: If you don't think it is...
dbaron: My comment was that the way the computed values of a bunch
of the properties in align works seems hard to implement
for us because they're unusual in ways we haven't done
before and we have optimizations that rely on not doing
those things. We could hack around but it may be useful to
make those less magical properties.
dbaron: That's more thinking than talking on telecon.
glazou: TabAtkins said he'd reply. But he's not here right now.
dbaron: I don't see a reply on the list.
<TabAtkins> I haven't replied yet, no. Was sick most of last week.
Houdini at TPAC
---------------
<gregwhitworth>
https://github.com/w3c/css-houdini-drafts/wiki/TPAC-F2F-October-2015
glazou: There were some suggestions to meet on Thursday or Friday,
but some of us will be at other WGs and some will leave. I
have not followed the current status of the conversation,
can someone summarize?
glazou: We don't have Rossen. Right.
Florian: I can try. I think current status is we should try and
meet. Days with the CSS WG meeting aren't good, the rest
is fuzzy.
glazou: We'll all be busy all the days. We already have AC and AB
meeting overlap. Plenary day is for the plenary. There's
the meetup on Sunday. The number of available slots is
decreasing quickly.
<TabAtkins> I don't personally think we'll need anything beyond a
plenary-day meetup.
gregwhitworth: Rossen asked on the list...we agreed at Paris to
get together for a handful of hours on the plenary
day. The link is to the wiki and we were trying to
get a sense of who would be there. We were trying
to get a sense of would the right people be there.
There may not be a reason to talk about those extra
days.
gregwhitworth: If people would put in the wiki if they're
interested and capable it would help to put it in.
<fantasai> gregwhitworth, Doodle link? http://doodle.com/poll/4acs3t47cfp4vc5z
glazou: On the plenary day there will be breakout sessions and I
think there's two consecutive ones on the Wednesday.
gregwhitworth: That's what we agreed to, dino was looking for more.
If you're able to attend on Thursday or Friday or
neither, put it on the wiki and that way we can see
if there are even enough people to make it
worthwhile to meet.
glazou: Okay. Let's do that.
fantasai: I'll link the doodle to the wiki.
glazou: Okay.
Computed Value for text-orientation: sideways or sideways-right
---------------------------------------------------------------
<glazou> [member only link]
https://lists.w3.org/Archives/Member/w3c-css-wg/2015JulSep/0260.html
[public link]
https://lists.w3.org/Archives/Public/www-style/2015Sep/0199.html
koji: sideways and sideways-right. We are planning to do it as an
alias, is that okay? When we do getComputedStyle() we want
one of them to be canonicalized value, but which one?
koji: Florian and I prefer sideways because it's shorter.
Florian: I think sideways-right is there for legacy reasons and we
may want to drop it from the spec if there's no content
depending on it. I think there is so we're keeping it. I
don't have an opinion as to if they should be aliases or
separate values, but if they are alias it should go to
sideways which is the value people should be using.
glazou: Other opinions?
glazou: Proposal is sideways. Objections?
Florian: There's two proposals. So, first proposal is treat
sideways and sideways-right as aliases. Second is what do
they compute to?
glazou: So comments on the two proposals?
gregwhitworth: Can I not object but get feedback? I don't have
much knowledge in this space.
glazou: That's fine. Is a week okay?
gregwhitworth: I think you can discuss and come to what people
agree upon. I can talk to the powers that be and
see if it's an issue for us.
myles: What is our historical policy on multi values that mean the
same things?
fantasai: I think this won't effect Microsoft because you don't
implement text-orientation yet.
gregwhitworth: That's good to know.
fantasai: I think this is a case where we want to drop
sideways-right now that we have sideways. We just need
one thing to distinguish and having it called sideways
is the best. sideways-right is now identical to sideways.
It makes sense to have one value. We may have legacy
content, but we should do that in the way that is
easiest for UA which is to compute to canonicalized
value.
Florian: And that legacy case is most likely epub and they prefix.
koji: Mongolian is probably using it as well.
Florian: Is there web content using Mongolian?
koji: Yes.
Florian: Okay.
glazou: Given what we said, Florian, can you summarize?
Florian: It's to drop sideways-right and just describe sideways as
what it used to do. Say for legacy compat UA may support
sideways-right value that does the same thing as sideways
and computes to sideways.
fantasai: Works for me. Other option was sideways computes to
sideways-right. The argument for that is we might have
sideways-left in the future and it's symmetric.
koji: Works for me too.
Florian: The counter argument is sideways-left probably won't be
needed in the future because the main use case is
addressed through writing modes. Even if we needed that
value it's not symmetrical because it rotates the
baseline. So I don't think we're locking ourselves out
because there are other good names besides -left.
<Bert> (I can't judge the legacy situation, but Florian's
formulation sounds good to me, i.e., 'sideways' is the
value and 'sideways-right' may be accepted on input, but
isn't in the OM.)
glazou: Any other comments or objections?
glazou: Given the number of people able to discuss it I'll declare
consensus
RESOLVED: Describe 'sideways' as what 'sideways-right' used to do.
State that for legacy compat UA may support 'sideways-
right' value that does the same thing and computes to
'sideways'.
glazou: Next two items are from www-style. We thought they could
use time on the call.
Float Pushed to Next Fragmentainer, What About Siblings?
--------------------------------------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Sep/0002.html
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Sep/0146.html
Florian: This is probably worth talking about.
Florian: The issue is that when a float won't fit and we push to
next fragmentainer, what happens to the content around
it? The first answer that seems obvious is that the
content stays and the float moves. But if there are other
floats after it, but smaller, if we leave them behind we
have out of order floats and we might not want that to
happen.
fantasai: We looked at a couple of test cases that leaned toward
not pushing content. If you have some floats and you
clear a float that that pushes it down to the next line,
that doesn't push the content, just the float. So I
concluded that the float moves, but it doesn't take the
content after and that's what Gecko does.
Florian: For inline content that seems okay. But should we say if
the neighboring content contains floats they also get
moved to the next fragmentainer?
fantasai: It's probably easier to be consistent about it.
* bradk is ambivalent about this
astearns: What about Morten's comment about positioned floats not
being able to go above the previous float's top.
fantasai: I would do whatever CSS2.1 says to do and not add
anything more.
dbaron: One of the issues is pages are often printed, even if not
designed for it, so it's best for things to stay in
relative positions. Which I think argues for keeping the
same float ordering rules.
Florian: So does CSS2.1 mandate that floats stay in order or is it
done through the top thing?
dbaron: It's done through the top thing, but I've interpolated
that to applying across fragments as well.
<fantasai> " The outer top of a floating box may not be higher
than the outer top of any block or floated box
generated by an element earlier in the source
document. "
<fantasai> http://www.w3.org/TR/CSS21/visuren.html#float-position
fantasai: That's covered. When you push down a float subsequent
floats have to move, but text doesn't. So that covers
the case where floats are being used for layout.
Florian: Sounds good to me.
Florian: Do we need a resolution for the first part? Sibling
content that isn't floated stays in the fragmentainer, or
is that already there?
fantasai: We might as well resolve.
glazou: Can someone type the exact prose of the suggested
resolution?
<fantasai> RESOLVED: Moving a float to the next fragmentainer does
not move in-flow content that comes after the float.
<fantasai> (However, per CSS2.1, subsequent floats do move down.)
<Bert> +1 to that
<dauwhe> +1
glazou: So before it's actually resolved, let's let people read it
and object if they want.
Florian: Sounds good.
RESOLVED: Moving a float to the next fragmentainer does not move
in-flow content that comes after the float. (However,
per CSS2.1, subsequent floats do move down.)
glazou: Okay, second part?
Florian: I think the between parents is included in the resolution.
fantasai: We don't need to re-resolve because it's in 2.1
Clarification Proposal for Border Colors
----------------------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Sep/0106.html
glazou: adenilson sent this.
glazou: There was some discussion on www-style, but I'm not sure
enough for a decision.
fantasai: I think we can't really prescribe anything, but can
point out that colors close to black or white may need a
different color computation to make the border visible.
Blink is non compat anyway because they draw a solid
black line which isn't 3D.
fantasai: I'm okay to clarify the spec to say that colors close to
black or white need special handling, but I'm not
comfortable with anything more specific.
glazou: adenilson says the Blink fix was denied...I think the
issue is the lack of specification is blocking the interop.
fantasai: Well they're non-conformant.
glazou: I agree with you on one hand, but this is common enough
that we should have some specification.
fantasai: If someone wants to evaluate the existing implementation
and see what they actually do...
glazou: I'm not sure we'll have one algorithm for everyone. If we
have a spec in the future will the minority people be
willing to change.
fantasai: I don't think it's worth dealing with now, we can deal
with it in the future if someone wants to.
<bradk> Seems like the line should be lightened on one side and
darkened on the other, but I guess no browsers do that.
<dbaron> I think it might be worth finding out what the different
browsers do
<tantek> is there a test case?
<gregwhitworth> Tantek: http://codepen.io/Savago/pen/wBKRaX
<tantek> looking at test case
<tantek> URL to proposal?
<tantek> hah - we got this right in IE5/Mac
<tantek> who is complaining?
<gregwhitworth> tantek: in my opinion IE/MS Edge looks the best,
it's black with a slight lightning of the black
for the highlight areas
<tantek> gregwhitworth: I think FF rendering of black groove looks
pretty good too
<tantek> Safari/Webkit shows all black :/
glazou: I'll report this to adenilson and if he can spend time
that's great.
fantasai: And I would put this in level 4. I'm happy to clarify in
level 3 you can't make it solid black. It's already in
the spec, but maybe it's not clear enough. An algorithm
goes in level 4 and I honestly don't care enough to work
on it.
Florian: There's no problem adding what you said to level 3, if
this is enough to get people to fix we can deal with
later.
<Bert> (The shadow color was originally left vague on purpose, so
implementations could use whatever was common on the
platform, if anything. E.g., if the platform had a contrast
setting.)
glazou: Other opinions about the proposal?
glazou: Comments, objections, +1, -1?
<dbaron> what's the proposal?
glazou: Since we have an issue in the spec anyway, I think we
should have the clarification.
RESOLVED: Clarify in level 3 you can't make it solid black.
glazou: fantasai will you do the edit?
fantasai: Yeah.
glazou: Great. I'll report to adenilson.
glazou: That's it for the agenda. Anything to discuss?
Control Characters
------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Sep/0215.html
gregwhitworth: Can we cover the control characters?
gregwhitworth: Everybody is aware of what it is, I wanted to call
it out. FF and Chrome are shipping the change in
December roughly so we wanted to make sure the
release was timed. I wanted to call that out for
TabAtkins to reply.
gregwhitworth: I agree we shouldn't stop them, but do we want to
give web developers only 2 months to be aware of
this breaking change?
fantasai: It's not a huge breaking change. It only breaks things
that are broken. It's up to the Blink and FF teams. If
they're okay with the double coordinated release, that's
fine. If they'd like to loop in others wait for more
browsers that is fine as well.
fantasai: It's up to them how much...they'll be the ones taking
the flack.
gregwhitworth: I'm not bringing this up as a Microsoft/Safari
thing, it's more for the webdevs. As a previous
webdev getting boxes that suddenly appear on a
client's site is bad. Do we want to give more time
for webdevs to find out so that they know?
* fantasai thinks we need to hear from Mozilla and Blink ppl
<dbaron> So given greg's latest message, Jonathan Kew thought
maybe we needed to postpone the change.
Florian: If it's December the PR push needs to go out now.
gregwhitworth: I agree. I would have liked it to start months ago.
We'll still do this for us because we're still a
bit away. But this was more as a webdev concern.
dbaron: I said this in IRC, but I think Jonathan Kew was confused
by different things in different e-mails, but I think he's
leaning toward postponing a bit. I think he could go
either way. Given gregwhitworths's e-mail he added a flag.
gregwhitworth: And on the blink dev forum they aren't sure it's
worth the change because it's mainly about spec
purity...we're going back and forth because people
aren't sure it's good. If TabAtkins could reply so
we know where it stands and if we need to start the
PR beat. Microsoft will help with that because it's
important to get out there.
gregwhitworth: That's good. I brought it up.
CSSWG Twitter Account
---------------------
Florian: Process topic- when we announce spec releases we have the
twitter account that we share by sharing passwords.
Should we do it a better way?
<tantek> why mess with what works?
* fantasai agrees with tantek
<tantek> what problem are we solving?!?
glazou: So you're suggesting something like tweetdeck. I don't
like that because it forces people to use one app.
Florian: It's one from twitter.
Florian: tantek asks why mess with what works. The way we do it
with telling a password it might eventually leak.
<astearns> +1 to tantek - let's fix it when we have a problem
glazou: I don't see it as a big problem. We can change the
password if it leaks.
gregwhitworth: It would be a problem if they change the password
first....Or are you guys verified?
Florian: No. Somebody could steal the account.
tantek: I've had my twitter stolen and I got it back in less than
24 hours.
glazou: And this is a guy who has a one character twitter account.
You can't compete.
gregwhitworth: I know! I still agree with Florian but it's not
worth spending a ton of time on this.
glazou: I'm not sure I agree.
Florian: I can live with the current state of the world, I don't
think it's great.
Publications
------------
glazou: Speaking of announcements, the editors of a published spec
are supposed to announce it on www-style.
Florian: And the blog and twitter.
glazou: The MINIMUM is www-style.
<fantasai> http://wiki.csswg.org/spec/publish
glazou: Anything else?
glazou: Okay, thank you very much and talk to you next week!
Received on Thursday, 24 September 2015 11:00:59 UTC