W3C home > Mailing lists > Public > www-style@w3.org > March 2015

[CSSWG] Minutes Telecon 2015-03-18

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 18 Mar 2015 17:32:57 -0400
Message-ID: <CADhPm3vg58j2RRoKOcSqxor4-eOgtOZc8Xan0CmaO5wSxXbBPQ@mail.gmail.com>
To: www-style@w3.org
Generalizing 'region-fragment'

  - The 'continue' property received the most attention for
      - 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

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


  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

  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
  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
  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

  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
  Florian: There are interactions, but you still want overflow
           control separate from fragmentation control.
  Rossen: So how do you have overflow: visible and overflow:
  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
  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

  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

  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
  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
  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
  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
  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
  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
  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
  * 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
  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
  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
  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
  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

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'
  <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
  Rossen: If you're to specify logical properties it would work.
  Florian: It wouldn't work now because we don't have logical
  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
  <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
  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
Received on Wednesday, 18 March 2015 21:33:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:52 UTC