W3C home > Mailing lists > Public > www-style@w3.org > August 2014

[CSSWG] Minutes Telecon 2014-08-20

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 20 Aug 2014 20:30:29 -0400
Message-ID: <CADhPm3sZKYM1i3tW36teemNQVysssVE5EHHpPLXgYcbHUv=o4w@mail.gmail.com>
To: www-style@w3.org
Counter Styles

  - RESOLVED: New LCWD for Counter Styles

Backgrounds and Borders

  - RESOLVED: New CR for Backgrounds and Borders

Display Module

  - RESOLVED: New WD for Display Module

Overflow Issue

  - RESOLVED: Adopt proposal (available here:

CSS Text

  - RESOLVED: Accept the proposed resolution for issue 4
  - RESOLVED: Reject issue 51
  - For issue 21, the group agreed with making the soft hyphen the
       only place you can break in a word as long as there's an
       added contingency to handle words so long that one part still
       doesn't fit on the line after the soft break.
  - RESOLVED: Reject the issue (65)
  - Issues 59 and 72 are both waiting on feedback from Microsoft and
       will be addressed at the next F2F at the latest.

BECSS to Notes

  - RESOLVED: Move the three documents (behavior extensions,
       hyperlinks, and marquee) to notes


  Glenn Adams
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Sylvain Galineau
  Daniel Glazman
  Koji Ishii
  Dael Jackson
  Chris Lilley
  Peter Linss
  Mike Miller
  Shinyu Murakami
  Anton Prowse
  Liam Quin
  Matt Rakow
  Florian Rivoal
  Simon Sapin
  Alan Stearns
  Lea Verou
  Steve Zilles

  Sarah Holton
  Simon Pieters
  Dirk Schulz
  Greg Whitworth

  Scribe: dael

  glazou: Let's start.
  glazou: Any extra items?
  glazou: I have one.
  glazou: We're not far from the F2F and we need to add topics on
          the wiki.
  glazou: Please spend a few minutes thinking about it and adding
          items for the agenda.

Counter Styles
  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Aug/0194.html

  TabAtkins: It was published as LC a year ago.
  TabAtkins: When the period ended, there was still lots of good
             issues being produced by Xidorn. We think it's stable
             now, so we need to publish again.
  TabAtkins: Obviously there's substantive changes, so we want
             another LC. Standard 4 week period, I think

  glazou: DoC shows mostly green. I saw Xidorn added a few messages
          to the list.
  TabAtkins: I think the last message was "have you published a new
             draft?" but let's see.
  TabAtkins: Most recent items were in June and they were in the DoC.
  glazou: He has one on the 29th of July. Was it addressed?
  TabAtkins: That was the can you do a new LC message.
  glazou: No, there was one thing to be fixed in that message.
  TabAtkins: Yeah. Those were typos and they were fixed.
  glazou: Okay.

  glazou: Opinions or questions about publishing?
  Bert: I'm in favor
  <astearns> +1 to publish
  glazou: Me too.
  <sgalineau> no objection
  florian: I haven't been able to see details, but at a high level
           it looked fine.
  <ChrisL> +1 to publish
  dbaron: I'm in favor. I'd like to see it go to CR.
  TabAtkins: Me too, but per our requirements we need another pass
             before CR.

  Rossen: I just joined, what's this?
  glazou: Counter Styles
  Rossen: It's fine.

  RESOLVED: New LCWD for Counter Styles

  TabAtkins: I'll put it together this afternoon, Bert.
  Bert: Okay.
  <ChrisL> Bert, I will be traveling tomorrow so best if you do it
  * Bert to ChrisL: OK

Backgrounds and Borders

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2014JulSep/0119.html
  TabAtkins: Is fantasai around?
  TabAtkins: I can do the publication request.
  fantasai: We have a...we're ready for a new publication for
            backgrounds and borders. Let me see if I can pull DoC.
  <fantasai> http://dev.w3.org/csswg/css-backgrounds-3/issues-lc-2014
  fantasai: If you look at DoC...Main things we accepted most of the
            requests. We rejected comments from i18n about logical
            keywords because that's going into level 4. We rejected
            focus rings as out of scope, but explained how it works.
  fantasai: The main thing I'm concerned about is the spread radius
            formula that we didn't get a lot of feedback on, but all
            the comments were addressed.
  glazou: Opinions? Questions?

  ChrisL: i18n was okay with deferring to level 4?
  fantasai: Yes.
  <ChrisL> no objection then
  TabAtkins: I helped prepare the draft, so I approve of publication.
  <Bert> +1 to CR

  ChrisL: What was the problem with spread radius? Just no comments?
  <ChrisL> ok if its implemented then fine
  fantasai: We believe it's correct, it's just no one on the author
            side said it was good or bad except BradK said he was
            skeptical and leaverou was in favor
  <astearns> we implemented it for the margin-box value of

  MaRakow: I gave feedback a while ago but didn't get a chance to
           look at it, but I think it would be okay.

  ChrisL: Can I have a good link to the DoC?
  <ChrisL> http://www.w3.org/TR/2014/WD-css3-background-20140116/
           is 404
  <fantasai> http://dev.w3.org/csswg/css-backgrounds-3/
  * fantasai will fix that

  glazou: Any objections against a new CR?
  <ChrisL> +1 to publish
  <leaverou> +1 to publish
  glazou: Are people in favor?

  RESOLVED: New CR for Backgrounds and Borders

  * Bert to Chris: shall I start the CR process? Or do you want to
         do it?

Display Module
  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Aug/0214.html

  TabAtkins: We technically got a resolution to publish in January,
             but I've made enough changes...I'm sorry, we did
             publish a FPWD in January.
  TabAtkins: I hadn't made the edits we talked about in January F2F.
             Since then I've done a few other tweeks. I'd like to
             request a first WD. And fantasai, this is where you
             wanted to talk about merging?
  fantasai: That was for the upcoming F2F. But we wanted an update
            with the changes from the January F2F and we made some
            changes. We defined blockification and inlinification.
            We explain how it works for all display types.
  fantasai: We added a glossary of CSS2.1 terms. We folded in the
            entire proposal as asked. We also added hide value.
  fantasai: We wanted to have this make the box appear and
            disappear, not be about how it displays. This is the
            name we came up with. It's box-suppress with show, hide,
            and none.

  florian: I think the value names are fine, but for the property
           name I like the old one better.
  TabAtkins: It seems odd to make it look like it's a long hand when
             it's not.
  fantasai: That prefix might not be a bad thing. We wanted to make
            it clear this is about making the box go away or come
  florian: I think I liked it better prefixed with display, but the
           values and behaviors are fine to me.
  <bkardell_> +1 seems odd to look longhand and not be

  fantasai: Other comments?
  florian: Since we're moving away from having a LC, maybe we should
           bikeshed earlier?
  fantasai: I think we can publish now and bikeshed at the F2F.
  glazou: Previous WD is quite old so we should republish.
  glazou: Any objections to publishing?

  RESOLVED: New WD for Display Module

Overflow Issue
  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Aug/0286.html

  TabAtkins: This was from earlier.
  TabAtkins: dholbert had the reverse flex box. If it's column-
             reverse the initial scroll is set to the bottom. He
             says this makes sense and would like the flexbox spec
             to state this and create interoperability.
  TabAtkins: fantasai said she thinks it should be defined properly
             in alignment so that the Chrome behavior would fall out
  <fantasai> http://dev.w3.org/csswg/css-align/#overflow-scroll-position
  TabAtkins: So it now says if you align with an edge, you align the
             initial scroll position with that edge. That makes the
             correct behavior for flex happen because the flex start
             begins at the end. So it current would work correctly.
  TabAtkins: We think this is reasonable and we captured it in
             alignment already. We wanted to see if there are any
             objections to this approach.

  glazou: Questions?
  fantasai: This means that if you have a scrollable thing or don't,
            the initial alignment looks the same. The overflow is
            off to the other side from the alignment.
  Rossen: What happens when you have alignment and writing mode
          direction as opposite?
  fantasai: You set the scroll position according to the alignment
            and that accounts for the writing mode. So the default
            will match aligning to the start-start corner. This is
            about aligning on the scrollable element itself.
  fantasai: This is the property that says all my contents are
            aligned this way. So a scrollable box all contents are
            the scrollable area.
  dbaron: Key point is that the default references is, to the
          alignment does matter.
  dbaron: I'm a little worried that this doesn't affect margin auto,
          or text align, but I think I'm okay.
  TabAtkins: I think it's okay. Text alignment is another thing, but
             not as big of a deal. I could be wrong.
  Rossen: I'm okay with it as well. It makes sense.
  glazou: Anyone with an opinion or comment? Anyone else? No

  RESOLVED: Adopt proposal (available here:

  TabAtkins: Anyone with comments later, bring them to the mailing
             list. This is large and I want to make sure everyone is
             aware of it.

CSS Text
  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2014JulSep/0123.html

  fantasai: Let me find the message
  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Aug/0256.html
  glazou: The message is linked from what I posted above. That one?
  fantasai: Yes. I wanted to go over some things to make sure
            everyone is aware of them.
  fantasai: There's two issues about UAX14. We accepted something
            that breaks UAX14. There's the break character that's
            supposed to represent images and a glue character which
            is no break. So we interoperable-ly ignore the no break
            when it's between that character and a replaced element.
  fantasai: We had to change the spec to say we're reordering so
            that you violate the glue rule.

  florian: Do we have usage data?
  fantasai: I suspect this is well embedded because it's been around
            for a long time. We could dig out netscape to figure out
            how long.
  fantasai: People have relied on this in tables to put images
            together a lot.
  fantasai: I don't know how else to get usage data.
  florian: But there's a reasonable assumption it's common.
  fantasai: I think anyone trying to get not breaking would be
  glenn: Have you discussed this with unicode?
  fantasai: I haven't. All browsers are interoperable on this.
            People have been relying on images doing this so we
            should change the spec. I'm not happy with the result,
            it would be great to follow unicode.
  fantasai: If implementors have a way to evaluate breakage that
            would be great.

  ChrisL: Is it possible the unicode is wrong and we should contact
  fantasai: I don't think we should encourage anyone that isn't
            backwards...The unicode makes sense. I'd prefer that
            unicode is correct and we have a backwards compatibility
            constraint. If browser implementors think we can change
            that's great. We're stuck for web browsers, but no one
            else should have to deal.
  <ChrisL> OK that seems fair enough as justification to me
  ChrisL: That seems fine to me.

  glazou: Any objections?
  fantasai: Or does anyone think we change?
  glenn: Have you talked with browser vendors about changing?

  glazou: So, let's accept the resolution

  RESOLVED: Accept the proposed resolution for issue 4

  <fantasai> http://dev.w3.org/csswg/css-text/issues-lc-2013#issue-69
  fantasai: Next was the i18n group asked us to nominatively
            reference UAX14. We say here's some references...
  fantasai: The first problem is we're not sure if UAX14 is web
            compatible. Second is a lot of the breaks in the pairs
            table aren't okay without prioritization. You'll get
            weird results. Browsers don't do prioritization.
  fantasai: So we said no we won't normatively reference. We need to
            evaluate and we don't want to tackle that in this level
            of text. I think i18n didn't respond to that.

  <koji> I think this is actually issue #51
  fantasai: It's not issue 69...sorry.
  fantasai: That's that (below).
  <fantasai> http://dev.w3.org/csswg/css-text/issues-lc-2013#issue-51

  glenn: What do we tell users that don't want to break?
  fantasai: We don't normatively define line breaking rules in CSS.
  fantasai: If people want to not break, some characters are
            normatively referenced. the ones that are about control
            characters for line breaking. The others are
            informatively referenced.
  <fantasai> http://dev.w3.org/csswg/css-text/#line-break-details
  <fantasai> glenn, BK, CR, LF, CM, NL, and SG are normatively
  <fantasai> also WJ, ZW, and GL

  dbaron: My experience has been when people try and implement a new
          set of line breaking rules it has behavior that people
          don't expect. I don't remember how much of it was JIS X
          4051 and how much was UAX 14, but people would try a new
          line breaker and it didn't match the expected results.

  glazou: Let's go back to the current issue, 51. Anyone object
          against a rejection of the original comment?
  ??: I'm fine with that.
  <glenn> abstain
  glazou: So the proposal is to back that rejection.
  <SteveZ> I agree that we are not ready to normatively define line

  RESOLVED: Reject issue 51

  <glazou> http://dev.w3.org/csswg/css-text/issues-lc-2013#issue-21

  fantasai: Next was soft hyphens and hyphenation.
  <astearns> +1 to this change
  fantasai: We had said if you have a soft hyphen, that is
            prioritized. Epub said it was breaking anywhere close to
            soft hyphen and that was causing problems. So we said
            that if there's a soft hyphen you can only break at the
            soft hyphen, not anywhere else in the word.
  dauwhe: I agree.
  * glazou is ok with the change
  florian: So what happens if the word is too long? Any way you can
           break again?
  fantasai: I think it's just unbreakable.
  florian: If the word is too long, it's good if CSS is smart.
  fantasai: But most words aren't that long.
  * liam thinks fantasai doesn't speak German or Finnish ;-)
  * fantasai fair

  glenn: I've found in Thai that they often have long things that
         are space separated. It's a cheap way of breaking without a
  fantasai: Shouldn't they be using zero width space?
  glenn: I'm saying that we're seen that.

  astearns: This is used to turn off algorithmic hyphenation when it
            has an inappropriate result?
  fantasai: Yes.

  florian: I'm just wondering if the word is too long, should you
           say that if the additional break is needed you can say
           use automatic hyphenation and then if needed other break
           rules apply? Would that be useful?
  fantasai: I think that's a good question and I don't know.
  florian: I don't have an answer either, but I think it's worth

  glazou: So does this mean we need more investigation?
  fantasai: I don't know how to get the answer.
  dauwhe: "If needed" sounds pretty complex.
  fantasai: I think in this case it's if the word is too long.
  bert: But it may depend on what's on the next line.

  <liam> Barrow-in-Fur&shy;ness
  <glazou> « Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz »
  <glazou> or «λοπαδο­τεμαχο­σελαχο­γαλεο­κρανιο­λειψανο­δριμ­υπο­τριμματο­σιλφιο­καραβο­μελιτο­κατακεχυ­μενο­κιχλ­επι­κοσσυφο­φαττο­περιστερ­αλεκτρυον­οπτο­κεφαλλιο­κιγκλο­πελειο­λαγῳο­σιραιο­βαφη­τραγανο­πτερύγων»
for Lea
  * leaverou glazou: is that supposed to mean anything? It’s hard to
             understand it, but it seems like random words stitched
             together :p
  * glazou Lea, see http://en.wikipedia.org/wiki/Longest_words#Greek
  <glazou> ancient greek then
  * leaverou glazou thanks! I learned something new :)
  <glazou> :)

  fantasai: No, If you broke at the soft hyphen and you still can't
            fit...florian is talking about if you have a long word,
            you break at a soft hyphen, and the second half of the
            word is longer than the line. There's just this half a
            word. Are you then allowed to break at an auto-hyphen
            point, with that being the only thing on the line?
  bert: So not with a float? Or if you have another way to break the
        letters? It's hard to say it's absolutely needed.
  <astearns> the correct solution for that case is to add more soft
             hyphens to the word. You started adding them, so you
             need to add as many as may be required
  liam: This is the same with a word that can't be hyphenated.
        Usually systems give up and use a hyphen.
  ??: But we're the ones saying you can't break.
  liam: You can get something similar with place names. I pasted one
        example above. There's two questions, can you break at the
        explicit hyphen or can you break at other places in the
        compound word?
  florian: I'd break at the algorithmic hyphen points.
  <SteveZ> for what is it worth, it is also possible that neither
           half of the broken word fit on the very short line
  fantasai: I'm okay to say that if there's no other break points,
            if the word had a soft hyphen and you already broke
            there, you can then auto-hyphen.
  dauwhe: I can live with that. It's a rare situation.
  <liam> Rindfleischetikettierungsüberwachungsaufgabenübertragungsge&shy;setz
  liam: Not only if you already broke there. You may not fit the
        text before as with the crazy example above.
  dauwhe: So only hyphenate at the soft hyphen unless something
          really bad happens.
  fantasai: That seems reasonable to me and if we need to we can
  glazou: Okay.

  fantasai: Let's do issue 65
  <fantasai> http://dev.w3.org/csswg/css-text/issues-lc-2013#issue-6
  fantasai: That was i18n asking for more details on how Indic does
            letter spacing. We said no because we don't have the
            knowledge to do that. The UA is given the ability to do
            the right thing and you can figure that right thing out.
  florian: You have a note below in your e-mail that Chrome does an
           impressive thing.
  fantasai: Yes, but explaning Indic would be a spec to itself.
  ChrisL: There is an Indic language layout task force and we can
          defer to them until they come back? That allows us to
          defer the definition of "correctly" until they come to it.
  fantasai: I think it should be a separate document that we can
            refer to.
  glazou: I agree with fantasai
  <florian> +1

  glazou: So do we want the rejection? Any objections?

  RESOLVED: Reject the issue (65)

  fantasai: 72 is about control characters is waiting for Microsoft.
  fantasai: So that's open on you Microsoft people.
  <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Aug/0217.html

  fantasai: We're coming to consensus about cross inline properties.
            That might go into fonts.
  florian: What's the proposal?
  <fantasai> http://dev.w3.org/csswg/css-text/issues-lc-2013#issue-59
  fantasai: I'm not sure I'm quite clear on it.
  fantasai: We initially rejected this because distribute has been
            around since IE6. It's also fairly true it's not clear
            and doesn't match other values of the spec. This would
            be clearer and just by looking you can guess what it
  fantasai: We'd have to keep distribute, but should we make it
            legacy and have inter-character.
  florian: The problem is with scripting. Is this often used with
  fantasai: I can't image people would except arcane cases.

  dbaron: I'm not a fan of aliasing. I'd rather not have it.
  florian: The more scripts are involved, the less I like aliasing.
           But we have to define it.
  glenn: It's a serialization problem.
  fantasai: I think we were making it more of a duplicate rather
            than an alias.
  florian: I don't feel great, but I can live with it depending on
           browser vendors.
  Rossen: I wasn't here and I have to catch up on this. Can we table
          this to next week or the F2F? By that time I can talk to
          my tech guys and have a position on this.
  fantasai: Is this control characters or this one?
  Rossen: This one.
  glazou: 59 right?
  Rossen: 59.
  fantasai: I don't mind waiting another week.
  Rossen: Control characters is the same.
  glazou: Okay.

  Rossen: What's the urgency. Are you trying to push so it's ready
          for LC at F2F? Or is it okay at F2F?
  fantasai: We want to publish LC at the F2F at the latest. I think
            it will need to go there.
  fantasai: We can discuss there, but we want to be able to resolve.
  Rossen: I can have a response at the F2F at the latest. I'll see
          if I can get on the call next week from London.

  glazou: We only have 5 minutes. Anything we can do on text?
  fantasai: Do we have another topic? We can move on.
  glazou: So we have #6 or #8 on the agenda
  TabAtkins: I don't think we can do 6.

BECSS to Notes
  <florian> http://wiki.csswg.org/spec#dead-need-to-be-turned-into-notes

  TabAtkins: There's a handful of old specs that show up on TR, but
             they're dead. They don't even appear on our repository.
             Per W3C we're supposed to gravestone and make them into
             notes. Does anyone object to doing it with these? The
             list is on the wiki linked above.
  fantasai: Behavior extensions, hyperlinks, and marquee.

  fantasai: Can we rescind a non-recommendation?
  Bert: Yeah.
  * ChrisL talks into a muted phone and says the same as Bert pretty
  fantasai: It would be nice to have styling to say don't use.
  <SteveZ> a tombstone water mark
  <ChrisL> we can't rescind it but we can publish as a note

  florian: Blink dropped support for marquee, but that
           implementation was not even in line with the spec.

  TabAtkins: So any objections to these three being re-published as
             gravestone notes?
  glazou: No objections from me. Strong support.

  Bert: I agree. As an additional point, I put this topic on the F2F
        topic list. There are others that might need to be updated.
  TabAtkins: These were the super obvious ones. There were others
             that would need discussion.
  * dauwhe +1 to discussing others at F2F
  glazou: Any objection to moving the three doc to notes?

  RESOLVED: Move the three documents (behavior extensions,
            hyperlinks, and marquee) to notes

  TabAtkins: I'll prepare if you'll publish, Bert?
  Bert: Okay.

  fantasai: Are we okay to publish counter styles tomorrow?
  TabAtkins: Bert did a pre-request so he got an okay.
  <ChrisL> nice work bert
  fantasai: Excellent. Thank you.

  glazou: That's the top of the hour. Thanks everyone.

  <ChrisL> my regrets for next week (returning from SVG f2f)
Received on Thursday, 21 August 2014 00:30:57 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:43 UTC