W3C home > Mailing lists > Public > www-style@w3.org > October 2013

[CSSWG] Minutes Telcon 2013-10-09

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 10 Oct 2013 19:04:49 -0400
Message-ID: <CADhPm3ut+zwqBe-Xpn=fnJZs_hskR9OUVzP890jTrz7ypiKoTQ@mail.gmail.com>
To: www-style@w3.org
Edits to CSS Style Attributes

  - SimonSapin asked for information on how to add an errata to the CSS
       Style. Bert will help him out.

CSS Masking

  - RESOLVED: CSS Masking to Last Call with a 6 week period.

DOMMatrix, DOMPoint and DOMPointLiteral

  - RESOLVED: Split DOMMatrix, DOMPoint and DOMPointLiteral to own
         editor's draft.

Writing Modes

  - Rossen sent a clarification of his thoughts to the mailing lists,
         the implications of which were discussed.
  - Fantasai summarized the issues with glyph replacement when the item
         is rotated.
  - The group then began discussing the various solutions possible;
         Fantasai will send an e-mail to the group summarizing the three
         options available.

Shapes Syntax Issues

  - Stearns stated that most of the feedback received has been reflected
         in the current editor's draft.
  - The remaining issue is if shapes should model off of SVG, CSS
         position, or both.
  - Further discussion will occur on the mailing list.


  Glenn Adams
  Rossen Atanassov
  Mihai Balan
  David Baron
  Bert Bos
  Dave Cramer
  John Daggett
  Elika Etemad
  Justin Erenkrantz
  Simon Fraser
  Rebecca Hauck
  Dael Jackson
  Brian Kardell
  Philippe Le Hégaret
  Peter Linss
  Christopher Palmer
  Anton Prowse
  Matt Rakow
  Florian Rivoal
  Simon Sapin
  Dirk Schulze
  Alan Stearns
  Leif Arne Storset
  Steve Zilles

  Tab Atkins
  Brad Kemper
  Håkon Wium Lie
  Chris Lilley
  Simon Pieters
  Lea Verou

ScribeNick: dael

  plinss: Let's get started.
  plinss: We're till expecting a few more people.
  plinss: Any additions to the agenda?
  SimonSapin: Editing CSS Style Attributes spec
  plinss: Let's start there

Edits to CSS Style Attributes

  <SimonSapin> https://lists.w3.org/Archives/Member/w3c-css-wg/2013JulSep/0307.html

  SimonSapin: We agreed to have some changes in syntax for the spec.
  SimonSapin: We're talking about everything CSS 2.1,
  SimonSapin: Updates, recommendations,
  SimonSapin: And that should effect CSS Style Attributes spec.
  SimonSapin: According to fantasai we need an errata,
  SimonSapin: And I'd like to know if this spec needs another
              recommendation from the WG or if I can just edit it.

  plinss: Taking a look

  plinss: Is it only the generated version?
  plinss: Bert, are you on the call?
  plinss: Apparently he's not.
  <Bert>: You can't hear me, it seems :-( Will redial.

  SimonSapin: I'm sorry if the information is in the repository, I
              expected it not to be.
  SimonSapin: I can work from that.

  SimonSapin: My question now is how do I make an errata?
  fantasai: Bert needs to be the one to do the errata
  fantasai: Because he has access onto the CSS server.
  fantasai: You need to put the edits in and highlight them like Bert
            has done with other changes.

  * plh wonders if we can talk about

  plinss: Bert, you back?
  Bert: Can you hear me?
  plinss: Yes.

  Bert: You talking about errata?
  Bert: Tell me what it is and I'll put it in.
  SimonSapin: It's about errors in style attributes to maybe allow
              @rules in the future.
  SimonSapin: I can make edits. What format should it be in?
  Bert: If you make a patch that's easiest
  Bert: I need to put it in changes and errata documents so format isn't
  SimonSapin: Okay, I'll do patch

  plinss: To clarify, you're talking about @rules rules?
  SimonSapin: Not yet, but we're editing so we can add them in the
  SimonSapin: This is the same as CSS 2.1
  <SimonSapin> @page

  plinss: Great, so you and Bert will sort it out.

CSS Masking

  <krit> http://dev.w3.org/fxtf/masking/
  plinss: krit, you wanted this to go to LC?
  krit: We discussed CSS Masking at the F2F and I asked for review.
  krit: I got 3 responses
  krit: First was select function;
  krit: It lets you use compounds to select elements.
  krit: It was on the spec as at risk so I removed it for now.
  krit: Second was what a fragment is and how we can use it in CSS
  krit: I answered that on the mail list.

  krit: The last was clip()
  krit: Usually we have shorthand and extended, for this case we decided
        to use clip-path.
  krit: Fantasia thought it was confusing.
  krit: In the past we thought clip() would have both auto and shape;
  krit: It's a value that just applies to an element.
  krit: Clip-path has a specific shape,
  krit: That can be to any element.

  krit: There was a question about where we can have clip() address a
         specific function but needs compatibility examined.
  krit: We can't change this without a lot of issues
  krit: I think it's a worse scenario.
  krit: That's one reason we didn't have clip-path and clip-share.
  krit: Another reason is that auto is normal-clip.
  krit: So we'd need a new property for auto with clip as the short hand
        for both.
  krit: I think we should keep discussing
  krit: And use clip-path with clip() mandatory for implementations.

  <Zakim> -fantasai
  krit: I don't know what she got before she dropped off the cal.
  <Zakim> +fantasai
  <krit> fantasai: did you got everything?

  smfr: I'm in favor of deprecating clip() because it's so bizarre.

  krit: Did you get all I said?
  fantasai: I think so, let me check
  krit: I think we should keep what decision we made on clip properties
  krit: And keep deprecating clip().

  * sgalineau can't ever recall seeing clip used in the wild
  <smfr> sgalineau: i have seen it once or twice
  * sgalineau smfr, I bet you've seen half of all the uses!

  plinss: Opinions?
  smfr: If we keep what you have this is the last thing that needs

  smfr: Should clip-path create stacking context?
  krit: yes
  smfr: good

  plinss: I'm not hearing any objections.
  plinss: That's all the issues so it's ready to go to LC.

  krit: I'd say yes
  plinss: Objections to LC?
  SimonSapin: I think we'd still clarify how we take it to HMTL, but we
              can do that after LC.
  krit: Your concern is dependent on CSS 2.1 so doesn't block masking.
  krit: I don't think we need to clarify more because CSS 2.1 defines
        how fragments should work.
  SimonSapin: Can we find that?
  krit: I sent it to the mailing list.

  plh: I have a question, what group should we target to get comments?
  plh: Obviously SVG.
  plh: Any other groups?
  krit: I'll bring it to SVG and I'll send a review request to both
        public Mailing Lists.
  plh: Are we assuming that SVG is okay for LC?
  krit: I need both WG to agree.
  plh: What I'm hearing is we're not expecting comments outside those
       two groups.
  plh: So we shouldn't receive other comments.

  plinss: How long of a LC period?
  krit: What's usual?
  plinss: 6 weeks.
  krit: I'm fine with 6.

  RESOLVED: CSS Masking to LC, 6 week period

  Bert: Who are we asking for feedback?
  krit: SVG needs to approve a LC also.
  plh: Do we need to ask others?
  krit: Just SVG

DOMMatrix, DOMPoint and DOMPointLiteral

  plinss: Any followup needed?
  krit: There was confusion about if we do accept an ED.
  krit: The confusion was that glazou thought there was resolution and
        there wasn't.

  plinss: And what was the desire, to split to own document?
  plinss: Any objection to doing that?

  RESOLVED: Split DOMMatrix, DOMPoint and DOMPointLiteral to own
            editor's draft

Writing Modes

  jdaggett: I'm not sure how much we can get done without koji
  jdaggett: What should we do? Wait?
  Rossen_: Keep discussion on the list?
  jdaggett: I think it's technical in nature, so better on list
  Rossen_: Seems like it's going in circles on the list.

  jdaggett: I think it would help if you could clarify on list where you
            said drop 5.1.1.
  jdaggett: Is that was you meant?

  Rossen_: For whatever reason the mailing list has been rejecting my
  jdaggett: Are your posts going through now?
  Rossen_: I hope so, just sent one that went.
  Rossen_: Now there should be a reply to explain better what I meant.
  jdaggett: Okay, so I think I can respond on list.
  Rossen_: Let's keep it there for now; wait for next week if Koji can
           be there
  jdaggett: I have a schedule to talk with him this week.

  fantasai: I think I can explain if I understand correctly,
  fantasai: Just to add summary.
  fantasai: If I understand the issues are for codepoints defined in
            Unicode to be 'Tr' for vertical orientation should be
            replaced with an alternate glyph, if no substitution then
            display rotated default glyph.
  fantasai: Writing Modes currently allows two different behaviors: 1.
            assume the substitution is applied, doesn't matter if it
            isn't, you tried which is enough.
  fantasai: 2. is you check for substitution and if it's not
            possible, you manually rotate.
  fantasai: The objection from jdaggett; we should only allow one of

  jdaggett: That's not my only objection. Just practically speaking,
            there's no reason for a fallback.
  jdaggett: The number of code points that are effected by the fallback
            is in realm of 2 or 3 code points.
  jdaggett: My other objection is that there's an optional behavior,
  jdaggett: And it's not practical to make it normative because it's not

  glenn: I agree with jdaggett in part due to practicality.
  glenn: It's not straightforward to see if it made substitution or if
         it's related to what you think it was.
  glenn: Having to choose in user agent implementation it could be

  fantasai: Those were the two objections and Koji's concern about not
            allowing it is because there are implementors that want
            fallback rotation and there are places where the fallback is
  fantasai: So CSS would have to work harder to not rotate and it is
            built into lower levels of the system.

  florian: The second part of Koji's feedback is the one that concerns
           me the most.
  florian: I'm wondering if we could raise the requirements so that once
           we've tried the execution it is considered successful
  fantasai: Generally we don't say what layer something is implemented

  fantasai: That's the summary of the issues.
  fantasai: Koji also said UTC doesn't want CSS to disallow what they've
            built in.
  jdaggett: And that's what the wording of UTR50 reflects,
  jdaggett: There's no normative behavior defined, merely a statement
            that for Tr codepoints
  jdaggett: A rotated glyph *can* be displayed in fallback situations.
  jdaggett: UTR50 describes a character property, it doesn't define
            normative fallback behavior.
  jdaggett: It's merely a good default and the spec clearly states that
            higher-level protocols dictate behavior.
  jdaggett: My argument is that, in practice, for OpenType fonts the
            presence of vertical alternates,
  jdaggett: Obviates the need for fallback behavior.
  jdaggett: We can simply assume that vertical alternates are
            substituted for Tr codepoint.

  glenn: I agree that we shouldn't disallow if someone wants to
         implement a fallback
  glenn: I would oppose language that prevents that.

  hober: The purpose is interoperability so allowing optional behaviors
         decreases that.
  glenn: The problem is font support for specific features are optional
         and I don't know how to reconcile that optionality.
  fantasai: On interoperability, jdaggett has pointed out in real fonts
            this is an edge case that is rare and therefore
            interoperability isn't that important because it won't
            fundamentally break a page.
  fantasai: You will either get correct rendering or not, this allows
            for better fallback.
  fantasai: There's nothing the author would do differently.
  fantasai: It's a small case and hard to run into.
  fantasai: It's also a case where the optional behavior we want is
            better then default.
  fantasai: I don't think interoperability is a problem and allowing
            different behavior is worth differences in interoperability.
  <glenn> +1 re: fantasai's statement about interoperability being a

  sylvaing: That brings us back to Rossen's proposal.
  sylvaing: Not dropping the second part since most of the time it's the
  fantasai: Let me see paragraph, hang on.

  <Bert> q+ to ask if author has a way to force a glyph if the UA
        *doesn't* do what he wants?
  <fantasai> Bert, yes
  * Bert thanks fantasai

  jdaggett: Rossen is arguing that in the paragraph in section 5.1.1,
            the second sentence should be dropped.
  sylvaing: Most of the time the fonts are right so it's fine.
  jdaggett: I think if you put Tr into the category above and treat as
  jdaggett: In that paragraph the points that are UTR points and ??
            points are treated as upright.
  jdaggett: If you include Tr code points, it's fine to remove the
            second part.
  jdaggett: You need normative behavior.

  fantasai: I think removing the paragraph makes it less clear.
  fantasai: Right now it's clear there are two behaviors possible.
  fantasai: I don't think removing that sentence would improve it.
  jdaggett: One concern is what we're definitely creating ambiguity with
            optional behavior like this.
  jdaggett: If we leave ambiguity as is
  jdaggett: It becomes no longer clear to font designers if they need
            vertical altnerates for
  jdaggett: Tr codepoints or if they can omit and simply let the user
            agent display a rotated default glyph.
  jdaggett: That's a bad signal to send.
  jdaggett: Well designed fonts already include alternates for rotation,
  jdaggett: That's the ideal to which all fonts should converge.

  glenn: I don't think it's a problem. It's assumed platform supported.
  glenn: That doesn't prevent someone from using other systems.
  glenn: I don't think there's a problem, I agree with fantasai.
  <fantasai> glenn was giving example of shaping features etc.

  glenn: There's no interoperability problem
  glenn: There's already optional behavior because support for rotation
         is already optional.

  * dbaron thinks we're not succeeding at the bit about not having the
           discussion today.
  glenn: I think we're looking at this too much.
  * stearns the idea was to summarize the problem, which I think has
            been accomplished.
  * Rossen_ +1 to stearns
  * fantasai thinks we got a few important points here at the end.

  jdaggett: If that's the case we should remove the sentence.
  glenn: Taking it out doesn't do anything and leaving it doesn't have
         any harm. I prefer to leave it.
  jdaggett: To resolve this we need Koji to agree.
  jdaggett: Part of problem is that we don't understand why
            implementations desire this behavior.
  jdaggett: There hasn't been discussion about the reasoning behind the
            need for this fallback.
  jdaggett: So I think we should wrap up discussion here and do more
            with Koji on the list.

  plinss: Is there specific feedback from Koji to help reach a
          conclusion, or will we just continue discussion?
  jdaggett: I think need to see if he's comfortable with modification.
  fantasai: What modification? Remove the sentence?
  jdaggett: Remove the sentence with Tr put in the previous sentence.
  plinss: So you're okay with that if Koji is okay?

  florian: I'm not sure asking this to Koji will help because he's not
           the only one that disagrees.
  plinss: Anyone else that disagrees and not on call?
  florian: He needs to be involved, but just getting him to agree won't
           resolve the issue.
  plinss: My point is that if everyone else is here we can work here
          without Koji.
  florian: What I can hear is glenn and jdaggett disagree.
  glenn: I'd rather leave the sentence.
  fantasai: Yes

  plinss: That's your preference but can live with removing it?
  glenn: That's my preference, but if Koji drops it, that's okay.
  Rossen_: I don't think he wants it in
  fantasai: I think Koji can defer to unicode, but doesn't want it that
            he must defer.
  plinss: Anyone disagree with that viewpoint?

  plinss: So we have a solution and we need to confirm with Koji that
          it's okay.
  fantasai: Proposal is to defer to UTC50 and not say in our draft how
            to handle it.
  florian: I'm not sure that's a solution.

  jdaggett: There's several proposals, not one.
  fantasai: I'm looking at Rossen_'s and it defines U and not Tr.
  jdaggett: I think you need to add Tr to list.
  Rossen_: I think we made that clear 10 minutes ago; that's what
           jdaggett said first and I agree.
  fantasai: That's what Koji opposes

  plinss: Can someone summarize where we are and put on e-mail?
  fantasai: I think there's 3 things we can do.
  fantasai: Removing the handling of Tr and not saying how it's handled
            doesn't make sense.
  fantasai: Option 1 is to leave as is: Tr can work two ways and clarify
            that fonts are expected to provide glyphs.
  fantasai: Option 2 is remove the option for fallback rotation and
            require Tr to work like U.
  fantasai: Option 3 is remove any sentences referring to how to typeset
            anything and refer to UTR50 and expect it fill in details.

  jdaggett: I think 3 is what we've been discussing. It's what Rossen_
            posted on list.
  fantasai: That's #2

  plinss: Can someone take actions to document on this on the mailing
  jdaggett: I think for each we need clear wording.
  Dirk: Can you create a wiki?
  jdaggett: Better to be on the list.

  plinss: Again, can someone take an action?
  ACTION fantasai post options to list
  * trackbot is creating a new ACTION.
  <trackbot> Created ACTION-586 - Post options to list [on Elika Etemad
             - due 2013-10-1.

  florian: I'm not sure I understand ??? It doesn't say what you should
           be doing. Am I wrong?
  jdaggett: You're right. There's something that needs to connect the
            orientation classifications.
  jdaggett: If you look in spec you can find a whole paragraph.

  fantasai: For what it's worth, I don't like 3,
  fantasai: Given URT50 doesn't have details.
  plinss: Let's take it to the list.

  <florian> I am not sure I understand 3, because as far as I can tell,
            UTR50 merely describe the meaning of Tr, but does not
            describe what you should do.
  <dbaron> I'm not clear on how (1) and (2) deal with whether
           implementations are (a) required (b) forbidden (c) neither
           required nor forbidden from doing fallback.
  <jdaggett> I think for all three proposals we need explicit wording
  <fantasai> dbaron, (1) means (c), (2) means (b)
  <sgalineau> dbaron, I think #2 forbids fallback while #1 and #3 allow
  <florian> dbaron, sgalineau, I think #2 forbids, #1 allows, and #3
            does say
  <sgalineau> florian, yes. #3 doesn't say which means it doesn't
              requires or forbid fallback. up to implementors.

Shapes Syntax Issues

  stearns: We've gotten good feedback on shapes syntax.
  stearns: Almost all in are in the current ED
  stearns: Remaining is: do we follow SVG attributes and specify
           positions using x and y?
  stearns: Or do we use CSS3 position syntax and more complicated

  stearns: There's benefits to both.
  stearns: SVG lets us have consistant shapes.
  stearns: It's easy to translate between.
  stearns: CSS position syntax would let you describe a gradient and a
           circle in basic syntax.
  stearns: Question is how do we allow both approaches.
  stearns: That can be adding at keyword; width and height at x,y
  stearns: That lets us substitute x and y for options in position

  stearns: The other choice is to add shape as a function name and
           arguments would have a CSS syntax compatible way to describe
           everything CSS can describe.

  stearns: Is that a fair summary fantasai?
  fantasai: Yes
  fantasai: I wish I had a clear idea of what makes sense but I don't.

  stearns: We can do both, add at keyword to add in the future and put
           CSS syntax in the new shape function.
  fantasai: One thing that's on my mind is we need to have shape
            functions compatible with gradient so you can us both.

  fantasai: One disadvantage is if you want to place...the one confusing
            bit is percentages.
  fantasai: Now that I've been thinking gradient syntax treats position
            as the center of shape.
  fantasai: For circle and ellipses it doesn't matter how you do
            percentage because the position is in respect to a box.
  astearns: It only matters for rectangle because you're describing a

  fantasai: For consistency, the rectangle should be like and ellipse
            because it is the same except for the border.
  krit: I think it matters with SVG because shape syntax will be used
        for SVG.
  stearns: I think that encourages new shape that deals with percentages
           in CSS way and leaves existing shapes to be compatible with

  fantasai: Thing I'm dealing with is circle and ellipse is consistant
            with SVG so new shapes doesn't make sense for them.
  fantasai: Only place we have this issue is rectangle where SVG is
            different, top left corner,
  fantasai: Top left corner of the rectangle itself.
  krit: It's not always top left for SVG?
  fantasai: For what besides a transform?
  krit: For CSS you have top left, for SVG if you have a rectangle the
        coordinate space isn't top left.
  fantasai: I see.

  stearns: It's certainly not an issue with circle, but it makes sense
           to be consistant for all shapes so people using clip could
           still work.
  stearns: Doesn't make sense to move things over.

  plinss: It's the top of hour; proposals to move forward?
  fantasai: I want to think about krit's comments
  astearns: Let's discuss more on mailing list.
  plinss: Sounds good. Thank you everyone.

[Meeting ended]
Received on Thursday, 10 October 2013 23:05:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:03 UTC