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

[CSSWG] Minutes 2013-01-23

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 24 Jan 2013 15:49:16 -0800
Message-ID: <5101C87C.3060505@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:

   - Discussed fontloader interface and callbacks
   - RESOLVED: Add SVG attributes as CSS properties that apply only to SVG layout:
               cx, cy, dx, dy, fx, fy, height, width, offset, r, rx, ry, x, x1,
               x2, y, y1, y2 and maybe d
   - Discussed styling of placeholder text for input elements
   - Discussed updating CSS3 Box WD. Concern with republishing is the
     out-of-dateness / incompleteness of much of the draft.

====== Full minutes ======

Present:
   Glenn Adams
   Tab Atkins (late)
   David Baron
   Rik Cabanier
   Tantek Çelik (via IRC)
   John Daggett
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Rebecca Hauck
   Molly Holzschlag (via IRC)
   Peter Linss
   Alexis Menard
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Simon Sapin
   Dirk Schulze
   Alan Stearns
   Leif Arne Storset
   Steve Zilles

Agenda: http://lists.w3.org/Archives/Public/www-style/2013Jan/0299.html
Scribe: Rik

<SimonSapin> Well, that was easy :) https://github.com/Kozea/WeasyPrint/commit/829c758788

* mollyholzschlag is hovering on IRC, ping if you have F2F q's or want
                   to add yourself to the meetup
<jdaggett> what's the temp in tucson?
<mollyholzschlag> it's going to be 80f today in Tucson
<mollyholzschlag> bring yer bathing suits!
<jdaggett> holy cow

Administrative
--------------

   glazou: first item
   glazou: she sent a message to let Tucson know that we appreciate that
          they helped out with the meeting
   glazou: please book hotels and flights soon
   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Dec/0334.html

loadFont()
----------

   <jdaggett> http://dev.w3.org/csswg/css3-fonts/#fontloader-interface
   jdaggett: this is a proposal for a change
   jdaggett: basically the description of load in the current spec
   jdaggett: the version that is in the spec now will load a specific set
             of fonts but it doesn't set any callback
   jdaggett:  several people noted that this was cumbersome
   jdaggett:  and that it was easier to set up the callbacks at the same time
   glazou: why no onprogress callback?
   jdaggett: that would be possible
   glazou: yes, it think it would be useful to notify the user
   jdaggett: that would make sense. reasonable
   florian: yes
   jdaggett: yes, it makes things easier for users
   florian: yes, that is a good thing
   jdaggett: I will look at the font progress handler
   jdaggett: and will put it in the spec

   glazou: does anyone else have a comment?
   smfr: I'm a little confused
   smfr: why is this on the font loader interface?
   smfr: the modern way is to do addEventListener
   smfr: I'm unsure why you need all the 'on-' attributes on this font interface
   jdaggett: I need to think about that
   smfr: I haven't seen this pop up on modern APIs lately so don't know if it
         makes sense
   glazou: I agree with Simon
   <Ms2ger> Modern APIs like WebSocket?
            http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html#the-websocket-interface

   florian: in isolation John's proposal makes sense but if it's different
            from everything on the platform maybe not
   florian: we need a broader debate to discuss
   dino: it should be possible to base this on the XHR interface
   dino: it would be a single call like addEventListener with the event type
   dino: the current proposal is halfway in between of the 2 worlds
   <Ms2ger> XHR: http://xhr.spec.whatwg.org/#xmlhttprequesteventtarget
   <smfr> Ms2ger: i see 'onfoo' is used there, so maybe it's ok here
   <Ms2ger> The majority of new APIs do have onfoo, AFAICT
   <dino> Yeah, I misunderstood this to be *starting* font loads, rather
          than querying

   jdaggett: the whole point is to support the canvas use case
   jdaggett: I think this is better taken offline and will update the proposal

Viewport Units
--------------

   See last week's minutes
   http://lists.w3.org/Archives/Public/www-style/2013Jan/0220.html
   glazou: we're getting back to this this week
   rossen: I'm going to keep looking
   glazou: Is there anything new about viewport units
   rossen: no

   <fantasai> new about viewport units: http://lists.w3.org/Archives/Public/www-style/2013Jan/0312.html

SVG attributes and CSS properties
---------------------------------

+Tab_Atkins
   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Dec/0291.html
   krit: in SVG we have a lot of attributes such as x,y, width and height
   krit: and the SVG WG wants to turn those to CSS attributes
   * shepazu is on IRC and wonders if he should call in?
+Doug_Schepers

   krit: this was discussed before but the CSS WG wasn't really happy with
         it and want circle_x, rect_y, et
   krit: but it would be really nice if we can just keep the attribute names
   krit: because otherwise it's very confusing for authors
   krit: and they would have learn 2 syntaxes
   TabAtkins: I'm not very happy, but Dirk's argument is reasonable
   Tabatkins: so I'm OK with it
   dbaron: Are these REAL css properties? Or pseudo-properties that apply
           only to animations?
   krit: yes
   <shepazu> [not just about animations, useful for applying characteristics
              to all SVG elements]

   dbaron: do you have the list?
   krit: no, not right here
   cabanier: didn't Microsoft make that list?
   krit: yes

   smfr: there was an other proposal to add an SVG- prefix
   TabAtkins: I'm against that since some would be prefixes and others wouldn't
   TabAtkins: some would be prefixed and others that are already in CSS wouldn't

   … I'm looking for the list
   florian: are there collisions?
   TabAtkins: I don't think so
   <shepazu> [width, height…]
   TabAtkins: there are some that have the same name would take different
              parameters
   TabAtkins: x attribute on tspan and others are different
   TabAtkins: ... one accepts a list of values, one accepts a single value

-leif
   <krit> http://dev.w3.org/SVG/proposals/css-animation/animation-proposal.html
   krit: I pasted the list. Not all of those are necessary
   TabAtkins: most are for filters so we can eliminate those in the first pass
   <dino> The list does not include 'd'
   <dino> path::d
   rossen: in the CSS shapes graph we try to stick to the SVG syntax name
   rossen: I suggest we be consistent everywhere
   rossen: and use a similar naming convention
   <fantasai> are we doing camelCase -> camel-case?
   <TabAtkins> Oh god yes.
   * shepazu notes that they might be exposed in a CSSOM, in some way
   rossen: in that spec we tried to match SVG syntax as much as possible
   krit: the SVG WG is looking into synchronizing it better and be more
         like the CSS syntax
   krit: but it needs more discussion
   <shepazu> (I think the SVG WG would be okay with 'camel-case')

   <TabAtkins> cx, cy, d, dx, dy, fx, fy, height, width, offset, r, rx, ry,
               x, x1, x2, y, y1, y2
   TabAtkins: I pasted a list
   TabAtkins: most of them have very short names
   * fantasai had been thinking to use offset as a shorthand for offset-*
   dino: maybe it should be the list that do geometric modifications

   <dbaron> so we're not talking about the full list at
            http://dev.w3.org/SVG/proposals/css-animation/animation-proposal.html#def_attributes
            anymore?
   krit: David, that is correct. We're not talking about the full list
   <sylvaing> height/width take same values in SVG/CSS?
   <TabAtkins> Yes, height/width are the same as CSS

   <TabAtkins> If you ignore the gradient properties, you can drop fx, fy,
               and offset as well.
   krit: I don't think we should drop those to create very reasonable effects

   hober: would this affect non-svg elements?
   TabAtkins: no, they would be element specific
   hober: would there be author confusion since in SVG you can position
          with x and y but not with HTML
   TabAtkins: the geometric properties are specific to the SVG layout model
   TabAtkins: for instance, you can't use 'flex' on arbitrary elements
   TabAtkins: we can frame it as: these are SVG layout properties that only
              apply to SVG elements
   <shepazu> +1 to SVG layout spec
   <SimonSapin> `display: svg` ?
   hober: isn't that an argument for the SVG prefix?
   TabAtkins: no. it would be very confusing to have a bunch of SVG dashes
   shepazu: I think it would be confusing to have to use the SVG prefix.
           non-intuitive
   * sylvaing kind of likes the self-documenting/disambiguation of svg-
   <dbaron> we have 3-character property names like 'top'
   TabAtkins: since CSS is not going to use these short names, it's OK
              for SVG to use it

   dbaron: will width/height require units?
   TabAtkins: you are correct
   krit: we already do that. For example font size
   krit: so yes, it would require units
   shepazu: we're not proposing a change to CSS syntax and parsing

   glazou: is there a consensus?
   dbaron: what is the proposal?
   <TabAtkins> cx, cy, dx, dy, fx, fy, height, width, offset, r, rx, ry,
               x, x1, x2, y, y1, y2 and maybe d
   TabAtkins: this is the list of attributes that we want to promote into
              property names
   * sylvaing 'and this is how we ended up with the maybe property'
   <dbaron> so the proposal is to add CSS properties of those names
            corresponding to the equivalent SVG attributes?
   TabAtkins: yes

   dbaron: what happens with tspan?
   krit: we need to discuss in the SVG WG
   TabAtkins: it's resolvable. worst case we reset them to initial
              initial if they're in the wrong form
   TabAtkins: we'll figure something out
   shepazu: it's also possible that we abandon multiple values
   glazou: seems everyone agreeing. Are there objections?
   <dbaron> I'm not exactly happy about it, but not objecting.
   <hober> like dbaron, i'm not crazy about it, but i'm not objecting.
   * fantasai wonders what causes the unhappiness, other than the names
              being un-CSS-y.
   RESOLVED: accept the proposal: cx, cy, dx, dy, fx, fy, height,
             width, offset, r, rx, ry, x, x1, x2, y, y1, y2 and maybe d
             become CSS properties

Styling Placeholder Text
------------------------

   glazou: this requires synchronisation between browser
   TabAtkins: I can summarize the options
   TabAtkins: 1. use a pseudo name placeholder but is heavyweight
   TabAtkins: 2. provide the value pseudo element and a placeholder pseudo class
   TabAtkins: 3. add a color opacity or a foreground opacity
   TabAtkins: to make the text opaque without invoking a pseudo element
   <stearns> should do 3 regardless
   TabAtkins: this makes things match SVG

   sylvaing: the main problem is that all browsers do this slightly different
   sylvaing: I don't think we should pick pseudo-class vs. pseudo-element
             entirely over one particular default styling (opacity).
   sylvaing: I don't think opacity is a massive problem but
   sylvaing: Tab does have a point where sometimes where you want to set the alpha
   sylvaing: alpha of the foreground text
   sylvaing: there may be a case to make this a pseudo element
   TabAtkins: the rule is that you set the foreground and background color
   TabAtkins: and then you have to set a different color
   TabAtkins: unless they see a report that it's not working on the website
   sylvaing: they will see that right away
   glazou: yes, Sylvain is right
   sylvaing: let's not assume that opacity is the only default
   sylvaing: I don't want to pick the design that there is a weirdness with
             opacity in text
   sylvaing: this is the wrong way to approach the problem

   dbaron: we have hit problems in the past because people don't test with
           all browsers
   dbaron: the equilibrium is ending up on pseudo-element
   dbaron: people might develop in one browser and then not test as
           thoroughly in other browsers
   sylvaing: yes, we have a bad situation. but we shouldn't simply do what
             chrome does
   TabAtkins: I don't argue for Chrome behavior because it's silly
   TabAtkins: the point is what should we do for placeholder styling?
   TabAtkins: we haven't done anything in years
   sylvaing: I want to hear arguments for your points.
   TabAtkins: I'm arguing for making opacity possible to use as the default
              text styling, not that we have to use a pseudo-element
   [opacity on the input element would make the entire thing transparent,
    not just the text]
   glazou: we should not add new properties
   glazou: specific for an element
   dbaron: we should use fill-opacity then like SVG
   * antonp thinks fill = background (intuitively)
   <stearns> text opacity is useful generally, not just for this particular case
   <SimonSapin> +1 for text opacity, whatever the name
   TabAtkins: fill maps to backgrounds and stroke to borders
   fantasai: Not for text though. Text elements in SVG fill and stroke
             the glyphs.
   fantasai: People want to do gradient fills on text or stroked text
   fantasai: So suggest we adopt the SVG fill-opacity etc. properties,
             but say in CSS they apply only to text.
   TabAtkins:  ah. this sounds really useful
   krit: in webkit we have 2 properties
   glazou: can you summarize the 3 options?
   glazou: so we can discuss during F2F

   Arron: Back to original question of pseudo-element/pseudo-class
   TabAtkins: (???) the correct answer to go with the pseudo class if we
              can address the text issue
   Tab: If we had a general solution for text opacity, I'd be in favor of
        pseudo-class, since in general it's more powerful.
   <SimonSapin> select the placeholder vs. select inputs that are showing
                their placeholder
   sylvaing: We seem to agree that pseudo-class is generally better, but
             Tab is arguing that the default styling of placeholder should
             be to make the text semi-transparent; and you can't do that
             currently without a pseudo-element to take 'opacity'

   Arron: placeholder text is a pseudo-element by the definition
   * antonp agrees with Arron that architecturally the placeholder is a
            pseudo-element
   dbaron: There's an obvious logical explanation for it to be either
   dbaron: If it's a pseudo-class, it's a selector that applies to the
           whole input
   dbaron: It represents the entire element when it has a placeholder.
   dbaron: If it's a pseudo-element, then we're styling a thing inside
           the input.
           It represents only the placeholder text.
   dbaron: these are 2 different things
   <fantasai> i.e. input:placeholder -- subclassing inputs that are
                                        displaying placeholder text
   <fantasai> vs. input::placeholder -- pseudo-element containing placeholder
                                        text that fits inside the input element
   dbaron: If it's a pseudo-class, you can put a red border on any input
           element that is showing a placeholder. And it would go around
           the input element.
   <fantasai> [if it was a pseudo-class, the border would go around the
               placeholder text only]
   glazou: we only have a couple of minutes
   glazou: tab, can you summarize and give pros and cons
   TabAtkins: yes
   glazou: let's discuss during the F2F

   <tantek> FWIW - there's been so much discussion on this (placeholder
            pseudo class vs. element etc.) on www-style, in bugzilla (on
            Mozilla at least), that I think it might be necessary to
            discuss this at the F2F when we can point at things we are
            all looking at.
   galzou: and let's add it to the wiki
   <tantek> thanks glazou
   <tantek> glazou++

   dbaron: can we talk about it next week?
   glazou: I won't be on the talk next week and would like to participate
   <tantek> in the mean time, please dig up the www-style links to previous
            discussions (since 2010 I think)
   dbaron: we should make the change in FF 19 though so time is essential

   <glazou> TabAtkins, please also mention the spec that should contain
           the placeholder solution
   <TabAtkins> glazou, will do.
   <glazou> thanks TabAtkins

CSS3 Box
--------

   glazou: http://lists.w3.org/Archives/Public/www-style/2013Jan/0268.html
   glazou: can we update the WD?
   antonp: it's good to show people that it's being worked on
   antonp: there's a lot of things that will change
   antonp: not how CSS is doing things
   * Ms2ger thinks that's long overdue
   dbaron: I think there's stuff in the box editor's draft that is also in
           other working drafts, where the other working draft is more
           up-to-date on our current thinking, and we need to be extra careful
   glazou: are there any objections to republish?
   dbaron: I would like to look at it this week.

   SteveZ: what is the different treatment?
   antonp: the way ???? are defined. definition of containing block
   antonp: what we're trying to do is rewrite things so it's easier for
           other specs to refer to
   antonp: it's editorial but quite complex
   SteveZ: indicating why the treatment changes would help
   SteveZ maybe a paragraph in the status saying that it's a working in
          progress/heartbeat
   <fantasai> We should definitely have a warning that people should still
             continue to refer to CSS2.1 for implementation
   glazou: let's revisit next week
   glazou: please read the module
   glazou: I will be out next week

Meeting closed

====== Post-meeting IRC log ======

<krit> TabAtkins, fantasai: What is the status of gradients on Text?
<krit> TabAtkins, fantasai: just heard you mention it
<fantasai> Proposal I made was to use the SVG fill/stroke properties on text
<krit> sounds great! means you can apply patterns and gradients from SVG?
<krit> (btw, SVG WG decided to accept CSS Images on these properties as well)
<krit> do you have a link to this proposal?
<TabAtkins> krit: Yeah, their values would be "<color> | <image>".
<fantasai> It was just mentioned in passing on the call :)
<fantasai> It's been on my mind for years
<fantasai> not written down anywhere though
<krit>fantastic. I was actually about to write a mail about it yesterday
<fantasai> The one tricky bit is the interaction of 'color' and 'fill'
<fantasai> and making sure authors provide an appropriate 'color'
<krit> it would be great to push that forward
<TabAtkins> Yeah, the interaction is interesting, since the initial value
             for 'fill' is "black".
<krit> Need to check how we do it in webkit. Tab mentioned that we have
        special properties there: text-stroke and text-fill
<fantasai> yeah
<fantasai> I remember discussing text-fill with hyatt
<TabAtkins> I suspect our properties have "auto" as the initial value,
             or something like that.
<krit> hm, that would explain it
<fantasai> we could have that compute to SVG's initial on SVG elements"]
<TabAtkins> Yeah, that could work.
<krit> fantasai: Do you want to send the proposal?
<krit> fantasai: I can summarize the problem as well if you should not
        have the time.
<fantasai> krit: Go for it. I'm not super-familiar with SVG properties anyway
* fantasai just wants to reduce duplication

<TabAtkins> fantasai: You think we'd specify them in text-decor?
<fantasai> Seems like the logical place
<fantasai> it's in LC right now, though...
<fantasai> Probably we can draft it up and then figure out where to put it
<TabAtkins> Excellent, that means we can start a level 4 as soon as it
             hits CR. ^_^
Received on Thursday, 24 January 2013 23:49:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:04 GMT