- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 06 Jul 2011 16:55:08 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Discussed use of Media Fragments in CSS3 Images
- RESOLVED: CSS3 Fonts will normatively address same-origin restriction issue.
- RESOLVED: Publish CSS3 Images as WD.
- Daniel Weck asked everyone to respond to / review emails about css3-speech.
- F2F location status update
- Discussed edits to charter's FXTF joint deliverables
- ChrisL will start errata document for CSS3 Color to address issues 1, 2 in
http://lists.w3.org/Archives/Public/www-style/2011Jul/0025.html
- CSS3 Writing Modes and text orientation will be discussed next week.
http://lists.w3.org/Archives/Public/www-style/2011Jul/0004.html
====== Full minutes below ======
Present:
Tab Atkins (late)
David Baron
Kimberly Blessing
Bert Bos
John Daggett
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau (late)
Koji Ishii
John Jansen
Brad Kemper
Chris Lilley
Peter Linss
Divya Manian (Opera Software)
Alex Mogilevsky
Florian Rivoal
David Singer
Daniel Weck
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2011/07/06-css-irc
<anne> I cannot make it today.
<anne> As for an update. Bert is not around so FPWD request for CSSOM has
not been made yet. I suppose I could do that myself, but not before
this week is over.
<Bert> Hi Anne, I'm back.
<glazou> lol
<Bert> I'm just finishing the e-mail to plh and chairs@w3.org about CSSOM
<glazou> anne: you dismissed most of my proposals (css om issues) but they
are REALLY needed for content editors
<glazou> and I disagree with them dismissed if the WG has no opportunity
to discuss them
<glazou> you just have no idea how important they are for editors
<anne> Why is the WG not discussing them then?
<anne> That's what the mailing list is for, no?
<glazou> because that's my job to ask the WG to discuss them during a conf
call ?
<anne> Also, I'm somewhat familiar with editors. A lot of my friends are
involved with writing editors of some kind.
<glazou> I was waiting for your input first
<glazou> good ; when they reach their 6th or 7th one, let me know :-)
<anne> Wouldn't it be better to discuss this on the list?
<glazou> well, yes, but your mail just closed the discussion, it's too firm
<glazou> you're the editor, not the decider
<anne> I think Xopus has about four major iterations. Not sure about Silk.
<anne> Well if people disagree they should feel free to say so, certainly.
<glazou> or agree
<anne> I just don't think CSSOM is at the stage where we should add features.
<anne> Well, more features.
<glazou> I just disagree at least for the disabled attribute on <link> and
<style>
<anne> There are so much open questions that need implementation experience
and implementors looking at them.
<glazou> oh come on, we standardize things in CSS before implem
<glazou> and w/o implem experience
<glazou> that argument is not receivable
<anne> Yes, but these are already implemented
<glazou> nope
<anne> So we need to see what can be changed and how, and what the
constraints are
<glazou> you want to discuss the constraints on disabled ? let'd do that :-)
<glazou> let's
<glazou> trivial
<glazou> for the rest, ok, that requires implementors' input
<anne> I'm talking about the bigger picture, not the disabled attribute
in particular ;)
<glazou> the bigger picture is easy, anne
<anne> The disabled attribute would need to be added to HTML and the
xml-stylesheet specification
<glazou> the CSS OM is almost unusable in some parts, given the mess it is
<anne> Well I disagree
<anne> It's pretty complex
<glazou> if we write a new iteration of CSS OM that is not immediately
nicer and cleaner
<glazou> that's not worth it
<glazou> I can probably implement the disabled attribute in Gecko in 2 hours
<glazou> tests included
<glazou> anyway
<anne> Anyway, writing a new iteration of the CSSOM is about making it more
interoperable first
<anne> Just adding a bunch of features is not going to help existing
implementations
<glazou> then we disagree on the goal
<anne> It will only make it more of a mess
<anne> It does have some new features, like the value API, but it requires
updating the other APIs as well as they are all intertwined
<anne> So the faster we get that done, the faster we can move on to new things
<glazou> we'll see
<anne> I'm sure we will :)
<anne> Going for dinner now, have a good meeting!
<glazou> kojiishi: http://bluegriffon.org/post/2011/07/05/BlueGriffon-EPUB-Edition
<kojiishi> glazou: wow! wonderful!
<glazou> kojiishi: should be almost alone on the market...
<glazou> kojiishi: should be ready after the summer
Scribe: fantasai
Media Fragments
---------------
glazou: I sent email to list about that
glazou: dbaron asked why I sent the message
glazou: just to make sure my opinion reported to HCG was not only mine
glazou: The question was about image fragments, e.g. for backgrounds
glazou: can we use fragments to pick out a frame or piece of the image
glazou: to use as an image
<dsinger_> Exactly. We allow it's use IF it is defined for the media type
glazou: issue is whether that is defined in CSS or elsewhere
chrisl: CSS isn't defining it, it's by normative reference to media fragments
ChrisL: I agree that the media type should define what the fragments mean
ChrisL: Although they should, they often don't
glazou: We cannot serve as a substitute for other committees' specs
<dsinger_> The question is whether a conformant CSS client is required to
notice and process them
glazou: Each media type should define things for itself
<ChrisL> http://www.w3.org/TR/2011/WD-media-frags-20110317/#media-fragment-syntax
fantasai: Right, but we need the spec that's supposed to define things
to define things
fantasai: I don't understand what the issue is
glazou: The issue is that we don't have to define what means a fragment
identifier in URL notation.
fantasai: Is media fragments going to define it?
dsinger: We just have to define what happens when you use it in CSS
ChrisL: Which is what we do already. So let's close the issue
* fantasai is so confused
<Kimberly> No objection
glazou: ok, let's close the issue
* dsinger me 2...
* Ms2ger is all for closing issues
* dsinger loves to close issues when he knows what the issue is
plinss: So, to be clear, we're not trying to define what media fragments mean.
Bert: There's a minor issue with the current spec. It refers to Media
Fragments, but there's a parenthetical remark saying what to do
with it, i.e. clipping it out
Bert: Maybe that should not be normative
fantasai: Here's the problem. Media Frags says which portion of the image
the fragment represents
fantasai: but it suggests things like showing the whole image and
highlighting the selected rectangle
fantasai: which is not useful to us
<dsinger> If a fragment is present and valid for the media type, the
fragment is the image
<fantasai> http://dev.w3.org/csswg/css3-images/#url
...
<ChrisL> this is ratholing from the original issue.
smfr: The issue isn't just for CSS. If you use an image fragment in HTML,
you have the same ambiguity
plinss: So are we requiring the UA to understand media fragments or not?
fantasai: We are. If it's not clear, I'll make it clearer
plinss points out the note about backwards compat isn't clear it's about
nonconforming UAs
Cross-origin Fonts
------------------
<jdaggett> http://dev.w3.org/csswg/css3-fonts/#same-origin-restriction
jdaggett: I put the wording in the editor's draft, and as some of you know,
Glenn Adams from Samsung raised a formal objection a few weeks ago.
jdaggett: He's since rescinded that, but it brings up a fuzzy area where as
a group we haven't resolved clearly one way or another
jdaggett: Do we address this issue in css3-fonts, or some other spec?
jdaggett: There are two .. with same-origin restrictions
jdaggett: First is, a lot of licenses require blocking cross-site linking.
Right now they're doing this with Refererer checking
jdaggett: It would be nice to provide a better solution in the UA
jdaggett: The other issue is security and attack vectors.
* Ms2ger suggests keeping it
jdaggett: When cross-site linking is allowed freely, there are security
implications that are not clear when the design was originally
created
jdaggett: WebGL is an example of this
* scribe didn't catch the details
jdaggett: People like Bert assert that this is only a problem with script,
and should be dealt there
jdaggett: But scripting is a part of the web platform, so we need to
consider it.
jdaggett: The issue Glenn was bringing up was that Samsung thinks that
any form of restriction on content is a form of DRM and
therefore they don't want it.
jdaggett: I don't think he originally understood the security considerations,
but now does. But still doesn't like the first way
jdaggett: It's a contentious issue.
jdaggett: What I want to resolve today is whether we address the issue
in this spec.
jdaggett: We can push it to another spec, but that just increases non-interop
jdaggett: The current wording leaves enough wiggle room that the details
can be worked out after we go to CR.
jdaggett: If anyone wants to hold off on this, please state your opinion now.
<dsinger> the sentence saying "the default same-origin for @font-face is
XXX" -- what other spec. COULD that be in?
Florian: What Opera wants is not just to get that into another spec, our
position is that the 2 issues you described in fonts, these these
are [...]. The current proposal of using same-origin policy
resolves them
Florian: But Anne's From-Origin header solves them for more media types
Florian: If we use From-Origin, then we don't need to deal with in this spec
ChrisL: No, it does need to be referred to. The crucial thing is if it's
referred from @font-face, it's assumed to be same.
Florian: I agree that some people say that. I don't agree that it's the
best way to go.
Florian: Whether or not it should default to same, it's still better to go
to From-Origin
jdaggett: I disagree in the sense that if you have a From-Origin mechanism,
as Anne has specced it out, I don't think that means you can
drop any sort of wording in the CSS3 Fonts spec that refers to that.
jdaggett: Not putting that wording in makes that an optional features.
E.g. someone can implement css3-fonts, and not implement From-Origin.
jdaggett: I don't think that's a good thing, particularly from security
viewpoint
Florianr: If we have From-Origin, but say that when you use @font-face,
then saying that ..
Florian: Then that's not very different from using same-origin policy with
CORS.
Florian: Because of that .. not doing From-Origin, and not doing it would
be bad, because it's useful for more than fonts.
<ChrisL> That doesn't seem a logical response at all
Tab: If From-Origin is useful for many things, it will be useful for many
things. We do not need the super-case of implementing it for Fonts
in order to make the case for the From-Origin API.
Tab: I think From-Origin is a great idea. I don't think saying that
without CSS3 Fonts depending on it, it won't get implemented.
Florian: The issue existed before, but because of this fonts issue, if
we drop it I'm afraid that while it won't be rejected, it will
get sidetracked because the main driver stopped caring.
Tab: I don't think that's true. I believe others of us are interested.
Tab: roc believes that more things should have been same-origin by default,
and it should be easy to go back and fix them to be same-origin
jdaggett: The issue I have here is not whether From-Origin or same-origin
by default is better, what I'm trying to capture is whether we're
trying to capture some type of origin restriction is in this spec.
jdaggett: or whether we're dropping it from the spec and letting it happen
via some other spec
jdaggett: That brings the problem you're concerned about, of not having
fonts drive htis issue.
dsinger: The first issue is, whether you must *notice* the From-Origin
header and process it
dsinger: The second issue is, whether you must treat it as same-origin
by default.
dsinger: Which issue are we concerned about
<dbaron> I don't think what dsinger said makes sense.
<dbaron> since the browser can't tell whether the server knows about
From-Origin
<ChrisL> what dsinger said is a good summary and i don't see anyone on
this call actually, currently, objecting to it
...
szilles: One of the things that concerns me is that it should be possible
for the average person to use fonts with licensing restrictions
without going through a lot of trouble.
szilles: My concern about From-Origin is that it requires the server
to be set up specially before you can use the font
szilles: But many people do not have that level of control on the server.
szilles: If we want fonts to be used on the Web, we need to make this easy.
Tab: Yes, it's easy, unless you don't have server control
<ChrisL> so the default case means that it *is* easy for the common case.
no server config needed
jdaggett: Back to the issue: do we push this to another spec, or leave it
in the spec and try to work it out here
jdaggett: I don't want to resolve whether to use From-Origin or same-origin
today, just whether to deal with it here.
hober: I believe this is clearly the right place to say something about
this issue.
jdaggett: I do think it's the domain of the spec, but just resolve that
we're dealing with it.
dsinger: What's the "this" ppl want to push out?
dsinger reads out his two statements
dsinger: I can't see what other spec they could possibly be in
Florian asserts that the first statement isn't needed (noticing From-Origin)
Florian: We don't say anything about other HTTP headers
* fantasai wonders, what about FTP?
dsinger: From-Origin is an addition to HTTP. It's not part of the normative
HTTP spec that we reference.
jdaggett: What I'd like to resolve today is that the css3-fonts spec will
deal with the same-origin issue, not what we should do about it.
Are there objections to that?
Florian: I really care about From-Origin. Don't feel strongly about whether
it should be talked about in this spec, although I prefer not.
RESOLVED: CSS3 Fonts will normatively address same-origin restriction issue.
<ChrisL> btw I saw a call for consensus for first public working fraft of
from-origin, so its moving forward
CSS3 Images
-----------
TabAtkins: No changes to css3-images, except fantasai's request to revert
keywords to match last draft.
ChrisL: I read through a spec, some things a little weird, but no objection
to publishing.
plinss: any objections to publishing?
RESOLVED: Publish CSS3 Images as WD.
Brad: I had a small issue. Looks like you took a note about values of
background properties being used to repeat gradients, can you put
that back in?
TabAtkins: sure
CSS3 Speech
-----------
dweck: We can't request publication just yet. Processing the comments that
came in the past week
dweck: Just wanted to ask if ppl could go through replies on css3-speech
issues as they come in this week, and review.
plinss: Ok, everyone please review messages/spec and send feedback
F2F
---
sylvaing: Narrowed things down to two, one is the hotel on West Lake
sylvaing: The only wrinkle on that is that it's not something that the
MS venue dept works with.
sylvaing: Worst case we get Mariott downtown on the waterfront
sylvaing: Should be able to confirm by end of week
ChrisL: Can we confirm that MS is hosting the joint SVG-CSS meeting?
Because Adobe can't handle that many people.
sylvaing: Yeah
sylvaing: Only thing I haven't planned for is, right now assuming 30
people. Do we need more?
TabAtkins: Seems appropriate
sylvaing: Let me know if I need to crank it up
dbaron: How many from SVG?
ChrisL: 6-10
plinss: If we can get our members to sign up on wiki page and get an
accurate count, would be useful
<glazou> http://wiki.csswg.org/planning/seattle-2011
plinss: Anything else on F2F?
Charter
-------
<ChrisL> http://www.w3.org/2010/09/CSSWG/charter.html
plinss: joint modules with FX?
plinss: We talked about an email to www-style, haven't seen any responses
<plinss> http://lists.w3.org/Archives/Public/www-style/2011Jul/0000.html
<smfr>
http://lists.w3.org/Archives/Public/www-style/2011Jul/att-0000/FX_Task_Force_and_Related_CSS___SVG_Specifications_and_Drafts.html
ChrisL: Proposal to move forward was to get an extension
ChrisL: I made the changes requested to reorder deliverables in the charter
ChrisL: If we agree with recommendations in latest email from Vincent,
I can put that in as well
ChrisL: There was a request to do Transitions jointly
smfr: You mean Transforms?
ChrisL: reads out the list
smfr: 2D/3D Transforms
smfr: gradients
<ChrisL> agree that 2d and 3d transforms should be added
TabAtkins: Gradients is getting resolved, using a solution suggested by roc
a year or two ago. Don't need any particular joint work there.
ChrisL: There should still be coordination on that.
TabAtkins: yes
TabAtkins: Once we publish the next css3-images draft, I'll add some notes
on making SVG gradients and CSS Images interact
ChrisL: SVG offered to make Compositing a joint spec, if CSS is interested
ChrisL: If not, SVG will move forward with it anyway
ChrisL: But may have some applicability in CSS
smfr: Might have some interaction with Filters
ChrisL: My tendency would be to put it in joint work currently, just to
cover it
smfr: Sounds fine
<ChrisL> ok will put compositing as joint
* bradk doesn't like the orange line on the blue background, between the
words "interaction" and "domain"
plinss: Do you have what you need?
ChrisL: Yes
CSS3 Color
----------
plinss: We had an email raising an issue. Should we start an errata?
ChrisL: Yes, we should start an errata.
ChrisL: The first issue is trivial
<dbaron> what's the url of this?
<nimbu> http://lists.w3.org/Archives/Public/www-style/2011Jul/0025.html
ChrisL: Just need to add "This section is non-normative" to the intro
ChrisL: Second one is much more serious
ChrisL: Container needs to be refined for CSS, since for relpos/abspos
there's different behavior
ChrisL: Need to clarify 3.2 that treated doesn't affect the computed value
dbaron: I think his proposed wording isn't quite sufficient because
"treated as though it has the index: 0" also has an effect on the
painting level of descendents, which this doesn't mention
ChrisL: do you have better proposed wording?
dbaron: I think what's there already might be OK
smfr: What's there already is certainly better than his suggestion.
<dbaron> just change "except that 'auto' is treated" to "except that a
computed value of 'auto' is treated" to make it clear that it
doesn't change the computed value
smfr: Maybe "behaves as if its z-index were zero"?
fantasai: Could work. Subjunctive implies that it is not true.
ChrisL: For the third we might need some email back and forth to determine
best wording, but the other two I can do
ACTION: ChrisL update css3-color errata to handle issues 1, 2 in
http://lists.w3.org/Archives/Public/www-style/2011Jul/0025.html
<trackbot> Created ACTION-337
CSS3 Writing Modes
------------------
<plinss> http://lists.w3.org/Archives/Public/www-style/2011Jul/0004.html
TabAtkins: I remember reading your email and thinking, man, text is hard.
Florian: The content of the email, no, but whether we should keep this
approach we can do in 2 minutes
Florian: I think it's a good approach, keep going.
jdaggett: I think we need something like this as a default, but going
back to Eric Muller's statement, I think we need a good default,
but also an escape hatch.
jdaggett: Someone should be able to define for their text, these characters
are always oriented as such-and-such
fantasai: Do we need to have that character-level control in level 3?
fantasai: I don't think that's nearly as high a priority as everything
else in the draft and we shouldn't hold up all of writing-modes
to try to define character-level text-orientation controls.
jdaggett: text-orientation in general is nothing you can fake. You need a
standard behavior.
Florian: We need the default in level 3. Do we need the escape hatch in
level 3. I think not
szilles: If you don't have a clear statement of what the defaults are,
you can't do anything.
szilles: And I don't think we have a clear statement of what the defaults are.
jdaggett: That's what fantasai is trying to define here.
szilles: Don't recall what the escape hatch issue was. Markup is an escape
hatch.
jdaggett: I would ask that we put this on the top of the agenda next week.
jdaggett: If we try to address at the end of the call, will always be
starved for time.
Florian: I will only add that this is worth thinking about so don't drop
it yet.
plinss: So top of call next week then.
Meeting closed.
<RRSAgent> http://www.w3.org/2011/07/06-css-minutes.html
Received on Wednesday, 6 July 2011 23:55:51 UTC