- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 10 Oct 2013 19:04:49 -0400
- 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.
=====FULL MINUTES BELOW======
Present:
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
Regrets:
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
https://lists.w3.org/Archives/Member/w3c-css-wg/2013OctDec/0061.html
today
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
important.
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
future.
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
specifications.
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
discussed.
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
e-mails.
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
these.
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
important.
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
impractical.
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
implemented.
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
at.
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
non-issue.
sylvaing: That brings us back to Rossen's proposal.
sylvaing: Not dropping the second part since most of the time it's the
same?
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
upright,
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
list?
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
changes.
<fantasai> dbaron, (1) means (c), (2) means (b)
<sgalineau> dbaron, I think #2 forbids fallback while #1 and #3 allow
it.
<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
positions?
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
syntax
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
corner.
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
SVG.
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