SV_MEETING_TITLE -- 06 Jul 2011

<glazou> make logs public

<glazou> hi kojiishi

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

<glazou> er

<glazou> eheh Kimberly

<glazou> Zakim's pretty strict on syntac

<glazou> syntaX even

<kojiishi> hi glazou

<glazou> hi kojiishi, did you see our last announcement about BlueGriffon ?

<kojiishi> ah...sorry, no. I will.

<Kimberly> Salut glazou

<glazou> bonjour Kimberly

<Ms2ger> Bonjour Zakim

<glazou> kojiishi: http://bluegriffon.org/post/2011/07/05/BlueGriffon-EPUB-Edition

<nimbu> Zakim: +1.206.522.aaaa is me

<glazou> who is nimbu ?

<nimbu> divya manian glazou

<glazou> welcome !

<nimbu> :)

<kojiishi> glazou: wow! wonderful!

<glazou> :)

<glazou> kojiishi: should be almost alone on the market...

<nimbu> :(

<nimbu> thanks glazou!

<glazou> kojiishi: should be ready after the summer

<scribe> ScribeNick: fantasai

Additional items

jdaggett: font same-origin restriction

Media Fragments

glazou: I sent email to list about that
... dbaron asked why I sent the message
... just to make sure my opinion reported to HCG was not only mine
... The question was about image fragments, e.g. for backgrounds
... can we use fragments to pick out a frame or piece of the image
... 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
... I agree that the media type should define what the fragments mean
... 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
... 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

<Kimberly> No objection

glazou: ok, let's close the issue

plinss: So, to be clear, we're not trying to define what media fragments mean.

<danielweck> DANIEL W.: just regained access to internet. Joining the call now...

<glazou> danielweck: ok

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
... Maybe that should not be normative

fantasai: Here's the problem. Media Frags says which portion of the image the fragment represents
... but it suggests things like showing the whole image and highlighting the selected rectangle
... which is not useful to us

<dsinger_> If a fragment is present and valid for the media type, the fragment is the image

http://dev.w3.org/csswg/css3-images/#url

scribe:

<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

<danielweck> DANIEL W. => damn, my usual SIP server is not working, and the Skype telephone bridge is rejecting the passcode ! :( (trying again)

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.
... 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
... Do we address this issue in css3-fonts, or some other spec?
... There are two .. with same-origin restrictions
... First is, a lot of licenses require blocking cross-site linking. Right now they're doing this with Refererer checking
... It would be nice to provide a better solution in the UA
... The other issue is security and attack vectors.
... When cross-site linking is allowed freely, there are security implications that are not clear when the design was originally created
... WebGL is an example of this
... People like Bert assert that this is only a problem with script, and should be dealt there
... But scripting is a part of the web platform, so we need to consider it.
... 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.
... I don't think he originally understood the security considerations, but now does. But still doesn't like the first way
... It's a contentious issue.
... What I want to resolve today is whether we address the issue in this spec.
... We can push it to another spec, but that just increases non-interop
... The current wording leaves enough wiggle room that the details can be worked out after we go to CR.
... 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 useing same-origin policy resolves them
... But Anne's From-Origin header solves them for more media types
... 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 sane.

Florian: I agree that some people say that. I don't agree that it's the best way to go.
... 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.
... Not putting that wording in makes that an optional features. E.g. someone can implement css3-fonts, and not implement From-Origin.
... 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.
... 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 seema 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.
... 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.
... 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.
... or whether we're dropping it from the spec and letting it happen via some other spec
... That brings the problem you're concerned about, of not having fonts drive htis issue.

dsinger: The problem is that first, you must *notice* the From-Origin header and process it
... The second problem I'm hearing is that you must treat it as same-origin by default.
... Which issue are we concerned about

<dbaron> I don't think what dsinger said makes sense.

dsinger:

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.

<dbaron> since the browser can't tell whether the server knows about From-Origin

szilles: My concern about From-Origin is that it requires the server to be set up specially before you can use the font

<ChrisL> what dsinger said is a good summary and i don't see anyone on this call actually, currently, objecting to it

szilles: But many people do not have that level of control on the server.
... 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

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

<ChrisL> so the default case means that it *is* easy for the common case. no server config needed

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

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.

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

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?

RESOLUTION: 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
... 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
... The only wrinkle on that is that it's not something that the MS venue dept works with.
... Worst case we get Mariott downtown on the waterfront
... 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
... 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?
... 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
... I made the changes requested to reorder deliverables in the charter
... If we agree with recommendations in latest email from Vincent, I can put that in as well
... There was a request to do Transitions jointly

smfr: You mean Transforms?

ChrisL: reads out the list

smfr: 2D/3D Transforms
... 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.

<glazou> danielweck: I have a comment on voice-volume ; will send a mail

ChrisL: There should still be coordination on that.

TabAtkins: yes
... 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
... If not, SVG will move forward with it anyway
... 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

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

<Florianr> Just noticed something about the minutes about CSS Font and From-Origin. we talked about whether the default should be "same". The minutes mention "sane".

ChrisL: Second one is much more serious
... Container needs to be refined for CSS, since for relpos/abspos there's different behavior
... 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

<scribe> ACTION: ChrisL update css3-color errata to handle issues 1, 2 in http://lists.w3.org/Archives/Public/www-style/2011Jul/0025.html [recorded in http://www.w3.org/2011/07/06-css-minutes.html#action01]

<trackbot> Created ACTION-337 - Update css3-color errata to handle issues 1, 2 in http://lists.w3.org/Archives/Public/www-style/2011Jul/0025.html [on Chris Lilley - due 2011-07-13].

CSS3 Writing Modes

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
... I think it's a good approach, keep going.

<dbaron> (which mail?)

<plinss> http://lists.w3.org/Archives/Public/www-style/2011Jul/0004.html

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

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

fantasai's comments to be inserted: that the rest of stuff in writing-modes is higher priority than a char-level escape hatch, so we shouldn't hold up the spec for that.

<nimbu> plinss: the seattle wikipage is not editable

<nimbu> i mean seattle f2f

<nimbu> :/

<plinss> ? checking...

<nimbu> http://wiki.csswg.org/planning/seattle-2011

fixed

try now

<nimbu> yep see those buttons

nimbu, what's your login?

<plinss> try it now

<nimbu> divya

odd...

divya, can you edit http://wiki.csswg.org/spec/css2.1 ?

<plinss> I just added her to the wg group

<nimbu> yep seems so

that explains it :)

<nimbu> :)

- DRAFT -

SV_MEETING_TITLE

06 Jul 2011

Attendees

Contents