[CSSWG] Minutes Telecon 2015-09-23 [css-ui] [css-writing-modes] [css-break] [css-backgrounds] [css-text]

'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