W3C home > Mailing lists > Public > www-style@w3.org > July 2011

[CSSWG] Minutes and Resolutions 2011-07-06

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 06 Jul 2011 16:55:08 -0700
Message-ID: <4E14F5DC.6080008@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
   - 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
   - CSS3 Writing Modes and text orientation will be discussed next week.

====== Full minutes below ======


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


   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?


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

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:42 GMT