- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 24 Jan 2013 15:49:16 -0800
- 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 UTC