IRC log of css on 2013-06-05

Timestamps are in UTC.

00:16:11 [RRSAgent]
RRSAgent has joined #css
00:16:11 [RRSAgent]
logging to
00:16:13 [trackbot]
RRSAgent, make logs member
00:16:13 [Zakim]
Zakim has joined #css
00:16:15 [trackbot]
Zakim, this will be Style_CSS FP
00:16:15 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
00:16:16 [trackbot]
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
00:16:16 [trackbot]
Date: 05 June 2013
00:16:24 [dbaron]
RRSAgent, make logs public
00:17:00 [dbaron]
Zakim, remind us in 8 hours to go home
00:17:00 [Zakim]
ok, dbaron
00:17:17 [glazou]
rrsagent, this meeting spans midnight
00:17:20 [zcorpan]
zcorpan has joined #css
00:17:52 [dbaron]
RRSAgent, this meeting does not span midnight
00:17:52 [RRSAgent]
I'm logging. I don't understand 'this meeting does not span midnight', dbaron. Try /msg RRSAgent help
00:18:27 [r12a]
r12a has joined #css
00:18:38 [shans__]
shans__ has joined #css
00:18:46 [dbaron]
RRSAgent, start a new log at midnight
00:18:56 [jdaggett]
RRSAgent, you look lovely tonight
00:18:56 [RRSAgent]
I'm logging. I don't understand 'you look lovely tonight', jdaggett. Try /msg RRSAgent help
00:21:01 [Kazutaka]
Kazutaka has joined #CSS
00:23:51 [krit]
krit has joined #css
00:25:38 [myakura]
myakura has joined #css
00:25:42 [nikos]
nikos has joined #css
00:25:57 [stakagi]
stakagi has joined #css
00:25:58 [jdovey]
jdovey has joined #css
00:26:15 [glazou]
jdaggett, send us a few meeting tables and power strips, we could use them immediately :-(
00:26:38 [jdaggett]
oh dear
00:27:15 [glazou]
why do you think we've not started yet ?
00:27:19 [jdaggett]
google japan has no power strips?
00:27:56 [jdaggett]
is brian birtles there? get him to run back to mozilla japan to fetch some
00:28:01 [jdaggett]
he's a good runner!
00:31:01 [dbaron]
birtles is here :-)
00:32:49 [jdaggett]
00:33:00 [jdaggett]
i saw a big order come in last week...
00:33:11 [jdaggett]
that stuff will kill you... ;)
00:34:00 [jdaggett]
00:43:13 [krit]
krit has joined #css
00:47:46 [jerenkrantz]
jerenkrantz has joined #css
00:49:04 [plh]
plh has joined #css
00:49:20 [Tav]
Tav has joined #css
00:49:35 [fantasai]
fantasai has joined #css
00:49:42 [jdovey]
jdovey has joined #css
00:51:29 [jerenkrantz]
Is there an agenda? Or, will we kick off with agenda bashing?
00:51:47 [stearns]
the latter, usually
00:52:09 [glazou]
jerenkrantz, what stearns said
00:52:24 [jdovey]
beanbags & slingshots at the ready…
00:52:44 [dbaron]
I took the opportunity to write
00:53:07 [jerenkrantz]
Since I am new, do we tend to do intros and is there a scribe for those who can't join here?
00:54:20 [dbaron]
ScribeNick: dbaron
00:54:23 [dbaron]
Topic: introductions
00:54:24 [liam]
dbaron, I added a bullet item to that wiki page, telephone access
00:54:48 [Cyril]
Cyril has joined #css
00:56:19 [koji]
koji has joined #css
00:57:47 [dbaron]
Present: Daniel Glazman (Disruptive Innovations), Elika Etemad (Mozilla), Simon Sapin, Philippe Le Hegaret (W3C), David Baron, Tamjong Bah, Rik Cabanier (Adobe), Dirk Schultze (Adobe), Cyril Concolato, Nikos Andronikos, Brian Birtles (Mozilla Japan), Cameron McCormack (Mozilla), Dean Jackson (Apple), ?? (NTT), Satori ??? (KDDI), Masataka Yakura (??), Tab Atkins (Google), Justin Erenkrantz (Bloomberg), Koji Ishii (Rakuten), Jim Dovey (Kobo), Shane Stevens (Googl
00:57:47 [dbaron]
e), Alan Stearns (Adobe), Richard Ishida (W3C), Alan Stearns (Adobe), Bert Bos (W3C), Rossen Atanassov (Microsoft), Glenn Adams (Cox), Jet Villegas (Mozilla)
00:57:55 [Koji]
Koji has joined #css
00:57:59 [heycam]
00:58:01 [dbaron]
Topic: Agenda
00:58:24 [dbaron]
Peter: There's also an FXTF wiki for agenda items in addition to
00:58:40 [dbaron]
heycam: The only ordering restriction is doug wants to call in for text wrapping, prefers early
00:59:04 [dbaron]
is shepazu available now-ish?
00:59:35 [myakura]
s/Satori ???/Satoru Takagi/
01:00:04 [plinss]
zakim, room for 3?
01:00:05 [Zakim]
ok, plinss; conference Team_(css)01:00Z scheduled with code 26631 (CONF1) for 60 minutes until 0200Z
01:00:16 [heycam]
shepazu ^
01:00:30 [Tav]
01:00:42 [dbaron]
Present+ Peter Linss (HP)
01:00:59 [Kazutaka]
s/?? (NTT)/Kazutaka Yamamoto(NTT)/
01:03:09 [dbaron]
Topic: Web Animations
01:04:00 [birtles]
spec link:
01:08:15 [dbaron]
dialing to Zakim failed, switching back to projector
01:09:33 [glazou]
01:10:39 [heycam]
shepazu, yes feel free
01:12:31 [dbaron]
birtles: wanted to give overview of web animation; getting close to asking for FPWD.
01:12:42 [Zakim]
Team_(css)01:00Z has now started
01:12:44 [dbaron]
britles: summary of where the spec has come from and what's in it now, so you know what you're looking at when review
01:12:49 [Zakim]
01:13:14 [dbaron]
birtles: microsoft asked that there be one model for animations on the web, not separate SVG animations and CSS animations, and suggested there should be an API. Request echoed by others.
01:13:27 [Zakim]
01:13:28 [Zakim]
Team_(css)01:00Z has ended
01:13:28 [Zakim]
Attendees were Doug_Schepers
01:13:36 [dbaron]
birtles: about 1 year ago, Adobe suggested I start concrete proposal for that; invited Shane (Google) to help, had suggestions about state machines
01:13:47 [dbaron]
birtles: presented last year in Hamburg, and FXTF agreed to take it on as a work item
01:13:58 [dbaron]
birtles: I've been working with Adobe and Google to produce specification
01:14:01 [birtles]
01:14:08 [dbaron]
birtles: overview of what's in it in this diagram
01:14:19 [dino]
dino has joined #css
01:14:22 [jerenkrantz]
jerenkrantz has joined #css
01:14:33 [dbaron]
birtles describes diagram
01:15:58 [dbaron]
birtles: (part of diagram description) SVG features not in the model mostly are features that generate animations rather than animations themselves
01:16:58 [dbaron]
birtles: We've cut a bunch of features recently; deferred integration with media and other features to keep it to a core model that roughly represents what's there already plus just a few extras
01:17:56 [dbaron]
birtles: Specification is quite long, because (1) it's the union of existing technologies (2) tries to define a lot of gray areas, particularly with regards to SVG. We've incorporated the features SVG references from SMIL into the model. More explicitly defined. (3) Style of specification; many non-normative explanatory sections.
01:18:08 [dbaron]
birtles: Apple's request to split into 2 parts: model first, then script api.
01:18:18 [dbaron]
birtles: we're focusing on the model, but the API often generates the most controversy/feedback
01:18:48 [dbaron]
birtles: going forwards, both Google and Mozilla have been talking about implementation strategies. Starting by implementing the model and pref-ing off the API, and then enabling the API bit by bit.
01:19:00 [dbaron]
birtles: The API is the controversial bit and the bit we really want toget right (hard to change later).
01:19:19 [dbaron]
birtles: About ready to ask for First Public Working Draft (FPWD) approval; a few edits we want to make first (drop a few interfaces).
01:19:31 [dbaron]
birtles: So what's there is hopefully what we'll be sending out later this week.
01:19:42 [dbaron]
birtles: So, just wanted to introduce this and ask if any immediate feedback or questions
01:19:56 [dbaron]
dino: slightly concerned that media was dropped. One of the things we considered important from Apple's perspective.
01:20:10 [dbaron]
dino: But I think this spec is in better shape before FPWD than most specs are after 5 or 6 WDs.
01:20:31 [dbaron]
birtles: Decision to drop media references is very recent; we have spec text around. So if that's a strong request from other vendors then we could look at it.
01:20:44 [dbaron]
dino: Nothing to stop a draft. Call out in the draft that it's been removed?
01:21:16 [dbaron]
birtles: Also looking to make that a separate module so it doesn't have to wait for v2. If it matures quickly could look at pulling into v1, but anticipate implementation issues that could hold back core model.
01:21:38 [dbaron]
stearns: on the other side: is there justification in the draft for the 4 new things in the model?
01:21:43 [dbaron]
stearns: rather than just describing the union?
01:21:55 [dbaron]
birtles: there isn't extensive justification for each feature
01:22:23 [dbaron]
birtles: timing groups quite central to the model, come about with issues with SVG synchronization features. Custom effects could be dropped. iterationstart is a commonly requested feature and very minor addition
01:22:26 [jerenkrantz]
jerenkrantz has joined #css
01:22:38 [dbaron]
birtles: no justification per se except for use cases at te start
01:23:26 [dbaron]
dino: our feedback a while ago (but don't want to argue against this spec) was that we were concerned about the massive amount of new API to add in one step. Generally Web improvements are more successful when iterative rather than massive new feature (be interesting to know why?).
01:23:46 [dbaron]
dino: also suggested that Apple's main interest in this type of work is very much in the form of declarative approaches to animation backed by a strong api.
01:23:57 [dbaron]
dino: I think the strength of this spec is that it has a powerful API with a complete JS library.
01:24:14 [dbaron]
dino: We're more interested in how a web developer not knowing much about animations mark up their document so that things happen over time in the document
01:24:29 [fantasai]
dino: That's why we're interested in media
01:24:34 [cabanier]
cabanier has joined #css
01:24:39 [dbaron]
dino: The first way most people add time aspects to their document is video... we didn't necessarily want to have them add JS to do that.
01:24:57 [Zakim]
Team_(css)01:00Z has now started
01:25:04 [Zakim]
01:25:09 [dbaron]
dino: At SVG meeting earlier in this year, we discussed maybe a module to this spec to say that there's a way to apply changes in state over time, exposed e.g. by new CSS selector or class
01:25:23 [dbaron]
dino: so a developer would approach authoring by saying from 10s-20s, this is the state that applies
01:25:29 [jdaggett]
hmm, no zakim conf at 26631
01:25:32 [dbaron]
dino: so you could write CSS that applies when that state is ative
01:25:50 [dbaron]
dino: so a CSS developer could easily understand this -- no JS. When state applies, apply transitions/animations/styles/whatever.
01:25:53 [dbaron]
dino: but adjacent to this spec
01:25:59 [dbaron]
dino: more like what we were hoping to use this spec for
01:26:17 [dbaron]
birtles: I should emphasize that the API is not fundamental to the model; you can implement the model without the api.
01:26:31 [dbaron]
birtles: Those parts which are outside the model but are in CSS or SVG are defined in separate specifications.
01:26:39 [jdaggett]
heycam: you guys aren't connected to zakim, i'm the "first participant"
01:26:46 [dbaron]
birtles: For the SVG parts, we'd have an SVG specification (my next task).
01:26:59 [dbaron]
birtles: Likewise CSS animations level 4 could be expressed in terms of that model
01:27:12 [dbaron]
birtles: in media... doing as a separate model...
01:27:20 [jdaggett]
the 26631 one
01:27:27 [dbaron]
dino: primary use case readalong books in iBooks -- a kids book that has, say, 3 lines of text on the page
01:27:46 [dbaron]
dino: audio track in page, lines or words highlight along with audio track
01:27:51 [dbaron]
dino: want to avoid using script
01:27:55 [dbaron]
dirk: using SMIL for this?
01:28:01 [dbaron]
dino: Ever tried writing that in SMIL? It's crazy.
01:28:10 [Zakim]
01:28:30 [dbaron]
birtles: next specification I'll be working on is SVG mapping onto the model
01:28:49 [dbaron]
dirk: Your request is to review the spec give feedback, and end up with publishing FPWD.
01:28:54 [dbaron]
birtles: yes, will send request later this week
01:29:31 [dbaron]
dino: what's the state of your JS shim/polyfill?
01:29:41 [dbaron]
birtles: I'm not contributing to that; Google is.
01:29:44 [dbaron]
shane: what info do you want?
01:29:53 [dbaron]
dino: how complete relative to spec?
01:30:09 [dbaron]
shane: more complete than current spec? Up to date other than last 3-4 weeks.
01:30:16 [dbaron]
shane: on github, open source license
01:30:30 [dbaron]
shane: should be relatively easy for us to sync with last set of changes over a week or so
01:30:46 [dbaron]
birtles: have some issues with events marked in spec with "feedback wanted" -- we want more input
01:31:16 [dbaron]
glazou: did you want to ask for FPWD now?
01:31:32 [dbaron]
?: or give people time to review?
01:31:47 [dbaron]
dino: I think it's a high quality spec, I think the question is whether in scope or out of scope.
01:31:59 [Zakim]
01:32:00 [Zakim]
01:32:00 [Zakim]
Team_(css)01:00Z has ended
01:32:00 [Zakim]
Attendees were [IPcaller], Doug_Schepers
01:32:06 [dbaron]
glazou: do people want time to review?
01:33:24 [dbaron]
[various people happy with publishing]
01:33:31 [dbaron]
Bert: no time to review before July anyway, so don't wait for me
01:34:02 [dbaron]
RESOLVED: Publish Web Animations as First Public Working Draft (resolved by both CSS and SVG WGs).
01:35:26 [dbaron]
Topic: reusing stroke and fill properties
01:35:31 [dbaron]
heycam: topic added from CSS side
01:35:37 [dbaron]
heycam: did someone have a specific proposal
01:35:42 [dbaron]
Tab: it was me
01:35:47 [Zakim]
Team_(css)01:00Z has now started
01:35:51 [dbaron]
fantasai: we've had requests to be able to do fill and stroke on letterforms
01:35:55 [Zakim]
+ +81.36.384.aaaa
01:36:04 [dbaron]
fantasai: webkit has text-stroke property. Might make more sense to reuse existing SVG properties.
01:36:23 [Zakim]
01:36:25 [dbaron]
fantasai: Complication is filling with pattern or image of some kind... how to handle line breaks is complicated
01:36:26 [birtles_]
birtles_ has joined #css
01:36:34 [dbaron]
fantasai: stroking or filling with color is straightforward
01:36:43 [dbaron]
heycam: why do line breaks complicate things?
01:36:49 [dbaron]
fantasai: need to find the bounding box
01:36:59 [Zakim]
01:37:31 [dbaron]
[pause for Zakim debugging]
01:37:54 [Zakim]
01:38:13 [dbaron]
fantasai: might cut or take bounding box or separately per fragment
01:38:17 [dbaron]
01:38:23 [fantasai]
dbaron: we do sort-of have a property for this already
01:38:24 [jdaggett]
the webvtt guys have 'text-outline' as part of their spec
01:38:26 [dbaron]
dbaron: we do sort of have a property for this already:
01:38:39 [jdaggett]
fill/stroke would be a better way of supporting that
01:38:39 [dbaron]
fantasai: do we reuse that property or have separate control?
01:39:00 [dbaron]
heycam: what does box-decoration-break do? fantasai: determines how it's handled for borders and background
01:39:11 [dbaron]
fantasai: That's background, this is about foreground.
01:39:34 [dbaron]
heycam: That's one issue. Another is defining how color property and fill/stroke properties work together and whether their initial values allow same behavior for existing things.
01:39:41 [dbaron]
dirk: I think the first question is do we want something like that.
01:39:58 [dbaron]
dirk: Before we talk about page break or line break or whatever.
01:40:02 [Zakim]
- +81.36.384.aaaa
01:40:03 [Zakim]
01:40:03 [Zakim]
Team_(css)01:00Z has ended
01:40:04 [Zakim]
Attendees were +81.36.384.aaaa, Doug_Schepers, Vivienne
01:40:11 [dbaron]
fantasai: simplest are fill-opacity and stroke; fill could deal with later
01:40:17 [dbaron]
dirk: I think fill at least as important as stroke
01:40:50 [dbaron]
dino: webkit currently has custom property for gradients in text -- -webkit-background-clip -- horrible thing with backgrounds, for filling text. Can't then do background.
01:41:00 [dbaron]
dino: want to be able to say fill text with gradient/color/pattern; seems pretty standard for CSS
01:41:08 [dbaron]
fantasai: additional complication is that color inherits
01:41:18 [dbaron]
fantasai: so each element paints with its own color property
01:41:31 [dbaron]
fantasai: if you add more elements nothing changes unless you set properties on those elements
01:41:41 [dbaron]
fantasai: you want pattern to be consistent across an entire paragraph
01:41:48 [dbaron]
... with elements inside
01:42:18 [dbaron]
heycam: in SVG, two options (1) define pattern area in coordinate space of elements or (2) define relative to bounding box of element that's using that paint
01:42:31 [dbaron]
heycam: but for tspans within a text element we use the bounding box of the text element as a whole
01:42:45 [dbaron]
dbaron: don't think (1) works with CSS model
01:42:47 [dbaron]
heycam: agree
01:43:06 [dbaron]
heycam: so what happens with linear-gradient on a paragraph with multiple spans...
01:43:20 [MikeSmith]
MikeSmith has joined #css
01:43:37 [dbaron]
dbaron: background doesn't inherit
01:43:42 [MikeSmith]
RRSAgent, make minutes
01:43:42 [RRSAgent]
I have made the request to generate MikeSmith
01:44:06 [dbaron]
[not minuting entire discussion here]
01:44:17 [fantasai]
dino notes that fill inherits
01:44:28 [dbaron]
dino: fill/stroke/color inherit and background doesn't; don't want a new style of fill for every child
01:44:29 [fantasai]
fantasai: that would be a problem
01:44:48 [dbaron]
heycam: why would fill and color have different inheritance?
01:44:57 [dbaron]
fantasai: if you're setting a pattern need to know which element initiated the pattern
01:45:20 [dbaron]
heycam: seems odd for fill and color to have difference in whether they inherit, similar actions
01:46:07 [dbaron]
heycam: I think we should first see if people think it's a good idea for fill and stroke to work for text... then work out issues if people like it.
01:46:12 [dbaron]
dirk: always have option to have different properties
01:46:31 [fantasai]
dbaron: I think it is a good idea to use fill/stroke. Would like to see that work
01:46:44 [Zakim]
Team_(css)01:00Z has now started
01:46:46 [fantasai]
dbaron: We could do it by turning fill/stroke into shorthand that sets both an inherited and non-inherited property
01:46:52 [Zakim]
+ +81.36.384.aaaa
01:46:54 [fantasai]
heycam: ???
01:47:17 [fantasai]
dbaron: Say 'fill' is a shorthand for 'fill-pattern' and 'fill-root'
01:47:22 [Zakim]
01:47:28 [SimonSapin]
heycam: so having text-stroke and text-fill not inherited and shape-stroke and shape-fill (for SVG) inherited
01:47:47 [fantasai]
dbaron: latter of which has 'normal' and 'establish' or something
01:48:00 [fantasai]
dino: You only want this fill/stroke to apply to text
01:48:00 [dbaron]
dino: question is, do you only want this new fill/stroke to apply to text?
01:48:01 [Zakim]
01:48:08 [fantasai]
dino: It's text-stroke. Do you ever want to stroke the box?
01:48:08 [dbaron]
dino: that's one reason in webkit it's text-stroke
01:48:12 [dbaron]
dino: do you ever want to stroke a box?
01:48:18 [fantasai]
fantasai: That's what borders are for
01:48:18 [dbaron]
fantasai: that's what borders are for
01:48:27 [dbaron]
?: just on text
01:48:34 [shepazu]
fantasai: that's what borders are for
01:48:34 [dbaron]
dino: then why not just do text-fill and text-stroke
01:48:56 [dbaron]
dirk: if you say ... should be a shorthand ... inheritance problem ...
01:49:01 [dbaron]
dino: sounds fine to me
01:49:10 [dbaron]
fantasai: in SVG stroke just sets color of something ... weird
01:49:23 [dbaron]
heycam: might be beneficial for 'stroke' to be shorthand to stroke-paint and stroke-width and ...
01:49:30 [dbaron]
fantasai: yes, that would follow pattern of CSS a lot better
01:49:40 [dbaron]
dirk: what does stroke-paint stroke-width mean?
01:49:45 [dbaron]
heycam: stroke-paint would be what stroke is currently
01:49:55 [dbaron]
fantasai: you can set all the stroke-related properties
01:50:04 [dbaron]
fantasai: if you just want to touch the color you say stroke-paint
01:50:12 [dbaron]
heycam: might be more convenient for SVG anyway
01:50:19 [dbaron]
fantasai: possible without breaking the Web?
01:50:24 [dbaron]
heycam: yeah, probably
01:50:34 [dbaron]
fantasai: depends how often people use it in CSS syntax rather than in SVG file
01:50:46 [dbaron]
fantasai: because stroke-width: ...; stroke: ...; would reset the first
01:51:00 [Zakim]
- +81.36.384.aaaa
01:51:06 [shepazu]
(what would stroke: blue; do?)
01:51:08 [dbaron]
heycam: so I feel like somebody should look at these issues and come up with proposal forintegrating
01:51:14 [dbaron]
dirk: problem here is we have the attributes
01:51:22 [dbaron]
dirk: [too fast]
01:51:27 [Zakim]
01:51:33 [Zakim]
01:51:34 [Zakim]
Team_(css)01:00Z has ended
01:51:34 [Zakim]
Attendees were +81.36.384.aaaa, [IPcaller], Doug_Schepers
01:51:37 [dbaron]
heycam: we already decided to allow font shorthand as presentation attribute
01:51:38 [Zakim]
Team_(css)01:00Z has now started
01:51:43 [SimonSapin]
shepazu, if it’s a shorthand, set stroke-paint to blue and stroke-width to the initial value
01:51:45 [dbaron]
heycam: you take all the presentation attributes in a praticular order
01:51:45 [Zakim]
01:51:51 [dbaron]
dirk :cannot modify this order in te dom
01:51:57 [shepazu]
SimonSapin, then it won't break the web
01:51:57 [dbaron]
heycam: might not have made this change
01:52:07 [dbaron]
fantasai: for surethe stroke attribute would map to stroke-paint... it would have to
01:52:11 [dbaron]
fantasai: never mind
01:52:27 [dbaron]
heycam: anybody think it's a bad idea to try to allow paints in stroking text?
01:52:38 [dbaron]
Bert: principle is good, worried about syntax
01:52:52 [shans__]
shans__ has joined #css
01:52:56 [dbaron]
fantasai: in SVG, if you stroke a letterform, where does the stroke lie with respect...
01:53:02 [dbaron]
dirk: it half overlaps the fill
01:53:08 [jdaggett]
seems like we need someone to work on a draft proposal
01:53:15 [dbaron]
tav: can change the order now
01:53:28 [dbaron]
heycam: does webkit-text-stroke paint on top of fill or beneath?
01:53:33 [dbaron]
dirk: same as SVG
01:53:35 [jdaggett]
i think you want to have inset/outset control
01:53:44 [jdaggett]
look to postscript for a good model
01:53:52 [dbaron]
tav: most of the time you want fill on top of stroke
01:54:18 [dbaron]
fantasai: if you put fill on top of stroke, looks fine when fill is opaque, otherwise looks dumb
01:54:28 [dbaron]
fantasai: would also lead to author confusion about stroke width
01:54:38 [dbaron]
fantasai: so I agree with jdaggett, should have control over where stroke is centered
01:54:48 [dbaron]
dirk: ???
01:54:48 [jdaggett]
also, japan has *lots* of examples of double stroking of text
01:54:56 [dbaron]
heycam: we have proposal for that
01:55:01 [dbaron]
tav: should we put that in?
01:55:03 [dbaron]
dirk; we did
01:55:05 [jdaggett]
white stroke surrounded by black stroke
01:55:10 [shepazu]
+1 to controlling stroke centering
01:55:25 [dbaron]
Bert: if you're doing filling of text you might want text-shadow to have inset keyword
01:55:31 [dbaron]
fantasai: inset in plans for text level 4
01:55:58 [Zakim]
01:56:05 [dbaron]
dirk: stroke and fill don't need to overlap... have a new property so they don't need to
01:56:08 [dbaron]
heycam: called stroke-position?
01:56:17 [dbaron]
heycam: which we have a proposal for, to go in SVG2
01:56:44 [dbaron]
fantasai: I think Tab and I can take an action to draw this one up.
01:56:48 [glenn]
glenn has joined #css
01:56:55 [Cyril]
01:57:03 [dbaron]
ACTION fantasai with Tab, draw up proposal for using stroke and fill for CSS text
01:57:03 [trackbot]
Created ACTION-562 - With Tab, draw up proposal for using stroke and fill for CSS text [on Elika Etemad - due 2013-06-12].
01:57:15 [glenn]
+Present glenn
01:58:00 [fantasai]
shepazu, call in
01:58:52 [dbaron]
jdaggett: For text stroke and text fill, parameterization could be complication... would like to work through multiple proposals.
01:59:22 [dbaron]
Zakim, mute jdaggett
01:59:22 [Zakim]
sorry, dbaron, I do not know which phone connection belongs to jdaggett
01:59:36 [jdaggett]
02:00:01 [dbaron]
Zakim, who is noisy?
02:00:14 [Zakim]
dbaron, listening for 12 seconds I heard sound from the following: ??P0 (20%)
02:00:30 [dbaron]
Zakim, ??P0 is Meeting_Room
02:00:30 [Zakim]
+Meeting_Room; got it
02:00:45 [dbaron]
Zakim, [IPCaller] is jdaggett
02:00:45 [Zakim]
+jdaggett; got it
02:01:10 [Zakim]
02:01:19 [Zakim]
02:01:20 [Zakim]
Team_(css)01:00Z has ended
02:01:20 [Zakim]
Attendees were Meeting_Room, jdaggett
02:01:26 [Zakim]
ok, shepazu; conference Team_(css)02:01Z scheduled with code 26631 (CONF1) for 60 minutes until 0301Z
02:02:03 [Zakim]
Team_(css)02:01Z has now started
02:02:08 [Zakim]
02:02:09 [Zakim]
02:02:10 [Zakim]
02:02:16 [dbaron]
Zakim, ??P0 is Meeting_Room
02:02:16 [Zakim]
+Meeting_Room; got it
02:02:32 [Zakim]
02:02:52 [TabAtkins]
Cool, new meeting is working.
02:03:27 [Zakim]
02:03:34 [dbaron]
Zakim, [IPCaller] is jdaggett
02:03:34 [Zakim]
+jdaggett; got it
02:03:44 [jdaggett]
02:03:46 [jdaggett]
that's me
02:03:57 [jdaggett]
there's a tv nearby so i have to mute
02:04:14 [dbaron]
Topic: text wrapping plans for SVG
02:04:38 [dbaron]
heycam: so recently in SVG WG meeting yesterday or the day before we discussed how to satisfy requests for wrapping text in SVG, long wanted
02:05:02 [dbaron]
heycam: people may remember the proposal in SVG Tiny 1.2, for <textArea>, with text layout different from CSS... objections because different from CSS
02:05:18 [dbaron]
heycam: 2 things we want: (1) to do simple rectangular text and (2) text in shapes, which SVG also had a proposal for long ago
02:05:25 [dbaron]
heycam: so we want to follow CSS For text in shapes
02:05:38 [Tav]
02:05:39 [dbaron]
heycam: and we've been discussing simple discussion for our current text to wrap text to a particular width
02:05:46 [shepazu]
simple: and more powerful:
02:06:07 [dbaron]
heycam: tav will talk about what we need from arbitrary shapes perspective and doug will talk about simple rectangular wrapping
02:06:35 [dbaron]
tav: This describes what's in SVG 1.2 flowed text. Partially implemented by Batik and Inkscape
02:07:06 [dbaron]
tav: that didn't take -- was complicated and not consistent with CSS
02:07:14 [dbaron]
tav: looked at what we can do to keep consistent with CSS.
02:07:26 [dbaron]
tav: propose to use shape-inside, shape-outside, wrap-margin, wrap-padding
02:07:33 [dbaron]
tav: here's an example, with a shape in an SVG circle
02:07:47 [dbaron]
(showing examples from )
02:08:08 [dbaron]
tav: mocked up flowing between shapes (from 1.2 proposal), though told this conflicts with regions from CSS
02:08:14 [dbaron]
tav: and here's one with some exclusions
02:08:24 [dbaron]
tav: a couple issues, 1 is CSS region seems overkill for our needs
02:08:29 [dbaron]
tav: and not close to being finished
02:08:41 [dbaron]
stearns: what you want that's different is a comma-separated list of regions?
02:09:06 [dbaron]
dirk: so shape-inside and flow to the next shape at the same time
02:09:27 [dbaron]
tav: shows example with text flowing from circle to square
02:09:53 [dbaron]
stearns: in regions you'd have a list of selectors selecting ...
02:10:03 [dbaron]
dirk: he means shapes... he wants shape-inside to have comma-separated lists
02:10:12 [dbaron]
Bert: so why does the text go down one and then down the other?
02:10:37 [dbaron]
tav: how to do without using CSS regions... if you don't have CSS support? SVG doesn't rely on having CSS.
02:10:52 [dbaron]
Jet: and the rest of the words are just clipped?
02:11:09 [dbaron]
fantasai: so what happens if someone increases the text size?
02:11:12 [dbaron]
tav: just falls off the end
02:11:21 [dbaron]
rossen: ... overflow: hidden... on both ...?
02:12:06 [dbaron]
tav: next problem we have is SVG doesn't have <br> and <p>, though could probably rely on 'white-space', though maybe not ideal
02:12:20 [dbaron]
tav: question is what's the best way to do line breaks and paragraphs
02:12:55 [dbaron]
tav: one thing we could do is position text in tspans by having x and y. We'd keep them, but in flowing text you ignore them. But if it doesn't it can serve as fallback for old renderers.
02:13:06 [dbaron]
tav: though if renderer doesn't have right font, might be positioning problems, but would be readable
02:13:26 [dbaron]
tav: one thing SVG doesn't have is a wrapping context... doug has a proposal
02:13:37 [shepazu]
02:13:50 [jet]
jet has joined #css
02:14:01 [shepazu]
02:14:05 [dbaron]
doug: link to my proposal
02:14:16 [dbaron]
doug: there's a width and (optionally) height property on svg:text element
02:14:26 [dbaron]
doug: and it basically passes in the position established via x and y
02:14:35 [dbaron]
dougt: ... and the width, and optionally the height
02:14:45 [dbaron]
dougt: ... as the inner box (rendering area), and has CSS engine do text wrapping
02:14:53 [dbaron]
doug: cameron has rough prototype
02:14:59 [dbaron]
heycam: in local build
02:15:01 [dbaron]
02:15:21 [dbaron]
doug: Cameron was able to implement in a couple of days.
02:15:44 [dbaron]
doug: The idea is to treat SVG text like you would a paragraph or text in a div. If it has a width, it wraps to that width. If has a height, clips to that point.
02:16:02 [dbaron]
doug: options are allowing scrolling with overflow:scroll, allowing padding/margins. I don't have a strong feeling about padding/margins either way. I think important part is wrappiyng.
02:16:23 [dbaron]
doug: But the basic idea is to use the width property on the existing text element to wrap the text.
02:16:40 [dbaron]
doug: Advantage to that is that the natural fallback is that the text still appears but is not wrapped; better than not apperaing at all.
02:17:06 [dbaron]
heycam: In SVG, when I get to rewriting text chappter, I plan to define non-wrapping text this way:
02:17:23 [dbaron]
heycam: SVG currently has x and y attributes to specify positions for character (not glyph!) positions
02:17:31 [dbaron]
heycam: we're treating that as a ... for defining CSS layout of the text
02:18:00 [dbaron]
heycam: you set up a block that has indefinite width and treat the text element itself as the block and tspans within that as inline,s perform CSS text layout, and then if any glyph positioning, do that as a layer on top ofthe CSS layout.
02:18:17 [dbaron]
heycam: so to handle restricting the text to a width would just mean setting that initial block width to that width rather than being exceptionally wide
02:18:38 [Rossen]
Rossen has joined #css
02:18:41 [dbaron]
heycam: so purpose of talking about these 2 topics here was to see if you think we're heading of the rails in any particular way, or have any opinions on how better to integrate with CSS stuff
02:18:54 [dbaron]
heycam: so we don't work away for months and then have people say it shouldn't be done this way
02:18:58 [dbaron]
fantasai: I think this makes sense
02:19:11 [dbaron]
fantasai: I have concern about x and y positions and how that works with line breaking
02:19:26 [dbaron]
fantasai: line breaking determined by layout engine and could vary between engines, e.g., fonts, hyphenation engine
02:19:37 [dbaron]
fantasai: those glyph thingies probably assume a certain type of wrapping
02:19:49 [dbaron]
heycam: in the past without support for auto-wrapped text, people used x and y to manually wrap
02:20:18 [dbaron]
heycam: so as tav was describing for text in shapes, where x and y could be fallback positions, we'd do the same thing here for rectangular text, so in this mode x and y would be ignored when wrapping is supported
02:20:26 [dbaron]
heycam: doug, did you have different view?
02:20:33 [dbaron]
doug: I think variou soptions we could explore.
02:21:13 [dbaron]
doug: Key thing is I want CSS WG to understand we're proposing to treat text in SVG much like text in HTML, and use existing CSS text layout engine that browsers already have to do text wrapping.
02:21:28 [dbaron]
doug: I think this is simply solved by using what CSS already has, in SVG.
02:21:56 [dbaron]
doug: There may have to be tweaks or bits here and there, say text-alignment, alignment-baseline, for certain effects or other things... we'd have to specify that, but would run by CSS WG.
02:22:11 [dbaron]
glazou: Also in Mozilla's XUL have to include HTML inside of XUL.
02:22:17 [dbaron]
glazou: not specific to SVG and text
02:22:26 [dbaron]
rossen: how is this different than foreignObject?
02:23:05 [dbaron]
heycam: Was just about to say that I think there's a real desire to not have to resort to having to use foreignObject -- ugly feature syntactically -- for simple cases like rectangular text layout. But foreignObject would still always be there.
02:23:18 [dbaron]
heycam: But for simple cases would be nice not to have to escape into HTML world.
02:23:45 [dbaron]
dino: Shouldn't say these are simple cases. If you're going to do a CSS block, it should be a CSS island inside SVG with all the CSS properties.
02:23:55 [dbaron]
dino: weird, x,y is bottom corner in SVG top corner in CSS
02:24:23 [dbaron]
heycam: In my approach, I switched on whether width was specified, and made x,y be top/left when width was specified
02:24:35 [dbaron]
heycam: definitely would want to specify it like that, now you're in CSS mode, read over here
02:24:40 [dbaron]
tav: in that case fallback doesn't work
02:24:45 [dbaron]
dino: I'm not so worried about fallback
02:24:54 [dbaron]
dirk: margin/padding has.. (cutoff)
02:25:05 [dbaron]
doug: popular libraries like d3.js where people are doing labels
02:25:15 [dbaron]
doug: script library that makes SVG diagrams very easy
02:25:27 [dbaron]
doug: I talked to several people using d3, people want wrapping text without having to use HTML
02:26:03 [dbaron]
doug: for those cases having fallback to older browsers woud be really nice, fall back to one line
02:26:10 [dbaron]
doug: this is why I mentioned alignment-baseline
02:26:22 [dbaron]
doug: could say whether origin affects glyph cell or character cell, top/left or baseline
02:26:32 [dbaron]
doug: dino, I'm fine with saying "this is a CSS block and behaves like one"
02:26:54 [dbaron]
doug: whatever's easiest for implementors and authors... authorswould expect padding/argin
02:27:25 [dbaron]
dino: then hyphenation, kerning, etc.
02:27:36 [dbaron]
heycam: for nonwrapping case we'll just make all CSS properties work on single-line text too
02:27:57 [dbaron]
heycam: at least in Firefox (soon) we'll just do CSS layout underneath for text, so easy to let properties just work
02:28:09 [dbaron]
dino: so you're suggesting effectively flatten text content of element
02:28:09 [Bert]
02:28:18 [dbaron]
dino: basically flatten tspan positioning
02:28:30 [dbaron]
dino: if I say text width is 100 and inside tspans with x and y... tspans get thrown out
02:28:42 [dbaron]
heycam: tspans are effectively spans even in the single line case
02:29:03 [dbaron]
doug: part of my idea was actually that in case where you wanted to have a line break, break element, might use tspan with dx and dy
02:29:20 [dbaron]
doug: to allow simple breaking in SVG so you didn't have to pull in HTML to do paragraph
02:29:25 [dbaron]
doug: obviously lists etc. out of scope
02:29:37 [dbaron]
doug: for simple text breaking thought could use tspans for that
02:29:40 [dbaron]
dino: should be a single block
02:29:42 [Koji]
Koji has joined #css
02:29:44 [dbaron]
dino: if you want >1 block, use HTML
02:29:59 [dbaron]
dirk: why not have new element in SVG for anything from HTML world?
02:30:08 [dbaron]
heycam: like foreignObject?
02:30:15 [dbaron]
dirk: with no <html><body> etc.
02:30:26 [dbaron]
dirk: inside this tag you have HTML world
02:30:32 [shepazu]
02:30:49 [fantasai]
dbaron: You don't need <html><body> etc. inside <foreignObject>. Do need namespace
02:31:01 [dbaron]
dbaron: how much more violent agreement do we need here?
02:31:17 [dbaron]
heycam: Just wanted to make CSS WG aware of what we're doing so we can get course corrections; mail to list fine too.
02:31:37 [dbaron]
r12a: when you collapse the tspans, how do you separate the last word in the first tspan and the first in the next?
02:31:42 [dbaron]
heycam: don't really collapse
02:31:52 [dbaron]
dino: meant just ignore x and y attributes and use them as spans
02:32:09 [dbaron]
doug: I think these details can be sorted out in spec... don't need to go into them in this meeting.
02:32:17 [dbaron]
doug: What I'd like in this meeting is ...
02:32:29 [dbaron]
doug: was some concern in SVG F2F that CSS WG might have some objections
02:32:37 [dbaron]
dougt: so we wanted to socialize it with CSS WG
02:32:42 [dbaron]
02:32:51 [dbaron]
doug: so we wanted to make sure thought a good path forard
02:33:00 [dbaron]
doug: don't know if we need a resolution per se
02:33:13 [dbaron]
doug: nice to know if this is a reasonable direction
02:33:19 [dbaron]
glazou: I think you have that consensus.
02:33:48 [dbaron]
Bert: I'm not going to say what SVG should do... but why not just stick with foreignObject?
02:33:57 [dbaron]
Tab: You need to give it a height, you can't just flow an amount of text in.
02:34:15 [dbaron]
doug: Bert, the answer I've gotten from people doing it every day, people want 1 element rather than 6.
02:34:24 [dbaron]
Bert: soon you'll need hyperlinks, hyphenation
02:34:27 [dbaron]
various: already have those
02:34:51 [dbaron]
doug: if you need anything more complicated, you can use foreignObject
02:35:09 [dbaron]
Bert: fine by me, just seems like double-work for half solution
02:35:13 [dbaron]
Bert: but no objection
02:36:19 [jdaggett]
google japan cafe is yummy!!
02:36:43 [Zakim]
02:36:46 [Zakim]
02:37:27 [dbaron]
<br class="lunch" data-endtime="13:00">
02:38:38 [sgalineau]
sgalineau has joined #css
02:39:41 [shige-o]
shige-o has joined #css
02:42:03 [AndChat|474201]
AndChat|474201 has joined #css
02:42:58 [AndChat-474201]
AndChat-474201 has joined #css
02:46:25 [shige-o]
shige-o has joined #css
02:46:55 [AndChat-474201]
AndChat-474201 has joined #css
03:06:01 [Zakim]
disconnecting the lone participant, Meeting_Room, in Team_(css)02:01Z
03:06:02 [Zakim]
Team_(css)02:01Z has ended
03:06:02 [Zakim]
Attendees were Doug_Schepers, Meeting_Room, jdaggett
03:26:38 [Cyril_]
Cyril_ has joined #css
03:39:27 [jdaggett]
jdaggett has joined #css
03:46:16 [krit]
krit has joined #css
03:48:22 [glazou]
glazou has joined #css
03:49:01 [Rossen]
Rossen has joined #css
03:49:07 [shige-o]
shige-o has joined #css
03:49:17 [shige-o]
shige-o has joined #css
03:51:46 [shige]
shige has joined #css
03:57:48 [jet]
jet has joined #css
03:59:00 [jdovey]
jdovey has joined #css
03:59:45 [stakagi]
stakagi has joined #css
04:00:05 [fantasai]
Scribe: fantasai
04:00:47 [myakura]
myakura has joined #css
04:00:53 [fantasai]
cabanier: Compositing and Blending Level 1
04:01:01 [fantasai]
cabanier: Last year in Hamburg, made a proposal
04:01:09 [jdaggett]
jdaggett has joined #css
04:01:14 [fantasai]
cabanier: Since then trying to simplify the spec, to make sure can be implemented easily in browsers
04:01:18 [fantasai]
cabanier: Removed compositing in CSS
04:01:27 [fantasai]
cabanier: areas, removed that as well
04:01:34 [jerenkrantz]
does someone have the latest link for the ED?
04:01:41 [fantasai]
cabanier: also knock-out feature removed, because hard to implement
04:01:52 [cabanier]
04:02:25 [fantasai]
cabanier: Only 3 properties left in CSS:
04:02:29 [fantasai]
04:02:30 [fantasai]
04:02:33 [fantasai]
04:02:53 [fantasai]
cabanier: Change to bg blend-mode, only defines how backgrounds blend with each other. Simpler to implement
04:03:06 [fantasai]
cabanier: mix-blend-mode also restricted only to things inside its stackign context
04:03:21 [heycam]
i/Compositing and Blending Level/Topic: Compositing and Blending
04:03:37 [fantasai]
cabanier: Also specs out canvas
04:03:49 [dbaron]
q+ to comment on mix-blend-mode
04:03:52 [dbaron]
q+ to comment on background-blend-mode
04:03:53 [fantasai]
cabanier: different blend modes for canvas
04:03:58 [fantasai]
cabanier: implemented in FF, webkit
04:04:06 [fantasai]
cabanier: patches
04:04:35 [jerenkrantz]
what was the URL for that demo?
04:04:46 [fantasai]
cabanier shows off demo of canvas and different blend modes
04:05:04 [fantasai]
cabanier: If there's ocntent behind this box, won't affect blending with that content
04:05:15 [fantasai]
cabanier: Third feature is blending of elements
04:05:32 [fantasai]
cabanier: shows some text over an image, with different blend modes
04:05:51 [fantasai]
cabanier: Want to know if people are keen
04:06:11 [fantasai]
cabanier: mix-blend-mode creates a stacking context
04:06:19 [fantasai]
cabanier: and will blend only with things inside its stacking context
04:06:21 [jerenkrantz]
Link appears to be:
04:07:10 [fantasai]
dbaron: Part of what I was proposing was creating a stacking context
04:07:26 [fantasai]
dbaron: I would need to think more about blending only with things in its stacking context.
04:07:30 [fantasai]
dbaron: It's probably okay
04:07:40 [fantasai]
cabanier: Talked to roc and ppl on Chrome compositor team
04:07:49 [fantasai]
cabanier: roc def ok with this, Chrome team seemed ok with it
04:08:35 [fantasai]
dbaron: Other concern was, are there enough use cases for background-blend-mode to justify a separate property
04:08:47 [fantasai]
dbaron: Can certainly make some nice demos with it, but how many real author use cases will it work for?
04:09:01 [fantasai]
cabanier: If you want a gradient e.g. that goes over an image, or enhance contrast of an image
04:09:10 [fantasai]
dino: Question is, why not use tool offline
04:09:16 [fantasai]
cabanier: If you want to animate it, hard to do with a tool
04:09:40 [fantasai]
dino: One of my concerns is, seems like background-blend-mode will be easiest to implement, and ppl will use backgrounds as content because they want this effect
04:09:49 [fantasai]
krit: ...
04:09:57 [fantasai]
krit: text blended with background, very strong use cases
04:10:06 [fantasai]
krit: moreso in SVG world, because of different shapes
04:10:17 [fantasai]
krit: In HTML itself, text is very strong use case
04:10:27 [fantasai]
cabanier: They're talking about backgrounds
04:10:29 [fantasai]
krit: oh
04:10:42 [fantasai]
cabanier: It could be extended later
04:10:50 [fantasai]
cabanier: Some people made proposals wrt adding filters on top of it
04:10:54 [fantasai]
cabanier: could come in nicely
04:10:59 [fantasai]
krit: Filter has filter image functions
04:11:05 [fantasai]
krit: This could also be blended
04:11:09 [fantasai]
krit: ... isolation group
04:11:19 [fantasai]
krit: If you have different background layer, [...]
04:11:36 [fantasai]
krit: Filter effects has a filter() function, which takes CSS image as input
04:11:39 [fantasai]
krit: And can be animated
04:12:22 [fantasai]
krit: You can have different layers in background, some filtered, and can be blended with other layers
04:12:33 [fantasai]
cabanier: background-blend-mode is much lighter
04:12:44 [fantasai]
cabanier: using mix-blend-mode for this would create lots of layers
04:13:47 [cabanier]
04:14:23 [dbaron]
dirk: I think we can agree mix-blend-mode is the most important
04:14:41 [fantasai]
dino: ... not as powerful or useful. mix-blend-mode is what we really want to expose, but is very powerful and complicated
04:14:48 [fantasai]
krit: As specified, no so complicated
04:15:02 [fantasai]
dino: With disadvantage that authors have to understand when a stacking context may or may not appear in their content
04:15:08 [fantasai]
dino: Expect that rounds down to 0% of authors.
04:15:45 [fantasai]
04:16:07 [fantasai]
dino: As soon as you hover over a div, that because its opacity changed, blending mode changed
04:17:00 [dbaron]
cabanier: we want to be able to do that later, though. And might be able to use new value of 'isolate' property.
04:17:06 [fantasai]
krit: I think we agreed that we wanted to have full backdrop blending. But know it's hard to implement at this point
04:17:21 [fantasai]
krit: Saying "these properties create an isolation group", don't have to know about stacking contexts
04:17:27 [fantasai]
dino; that's handling it in one way
04:17:37 [fantasai]
dino: You specify starting blending
04:17:54 [fantasai]
04:18:09 [fantasai]
dbaron: Disagree with Rik's comment wrt adding ability to blend with opacity later
04:18:26 [fantasai]
dbaron: Once you have CSS properties working a certain way, pages depend on things working that way. can't go back and change it later
04:18:35 [fantasai]
heycam: Would add a new value to isolation
04:19:16 [dbaron]
dbaron: does the new value go on the element being blended or the one making the stacking context?
04:19:24 [dbaron]
?: new value goes on element making the stacking context
04:19:50 [fantasai]
dbaron: Kindof ugly
04:20:00 [fantasai]
cabanier: Could wait a few years, or have something useful now
04:20:23 [fantasai]
heycam: Is it bad to have this new isolation property value on the element that creates the stacking context?
04:20:25 [jerenkrantz]
(the seraphzz pen link doesn't seem to work with FF 21; but the adobe link does w/FF 21.)
04:20:34 [fantasai]
heycam: Or would you want to specify that where you're putting the blending operation?
04:20:36 [dbaron]
dbaron: no, it makes sense that it goes on the element forming the stacking context
04:21:17 [fantasai]
dbaron: Think people will probably put * { isolation: new-value; } and not worry about it
04:21:22 [fantasai]
cabanier: Not great for performance
04:21:29 [fantasai]
cabanier: So, maybe don't want to do that.
04:21:52 [fantasai]
dino: Suppose I've got this complicated document
04:22:02 [fantasai]
dino: Copy it to another document that has a video in it, suddenly doesn't work
04:22:12 [fantasai]
dino: Have document with 3 children, they blend with each other
04:22:23 [fantasai]
dino: I set the opacity on the middle one. What about it's children?
04:22:26 [fantasai]
cabanier: That's all fine
04:22:39 [fantasai]
cabanier: If your parent has opacity, you won't blend with its parent
04:23:53 [fantasai]
04:24:00 [fantasai]
dino: so, everything blends in its regular order in the document
04:24:11 [fantasai]
krit: ... z-index
04:24:44 [fantasai]
dino gives example of child with video descendant
04:25:45 [fantasai]
04:26:08 [fantasai]
dino: It's easy for Core Animation's compositor, can specify blending of child into its parent
04:26:10 [krit]
s/... z-index/z-index creates a stacking context and content can not blend with everything beyond it/
04:26:21 [fantasai]
dino: But what looks like parent-child relationship in HTML document isn't necessarily that simple in compositor
04:26:25 [fantasai]
dino: Example is 3D transforms
04:26:31 [fantasai]
dino: ...
04:26:39 [fantasai]
dino: Disconnected form your parent, so can't blend into it
04:26:50 [fantasai]
cabanier: At some point the 3D object is composited though
04:27:03 [fantasai]
dino: You could hit significant perf problems without knowing why
04:27:11 [fantasai]
dino: Have to flatten the 3D world
04:27:15 [fantasai]
dino: get those bits, etc.
04:27:20 [fantasai]
cabanier: it's the same math
04:27:52 [fantasai]
04:28:11 [fantasai]
dino: [something about not using compositing for web content]????
04:29:17 [fantasai]
dbaron: What do you mean by not using compositing?
04:29:43 [fantasai]
dino: have to manipulate tree heavily to do things like clipping, overflow, scrolling
04:29:58 [fantasai]
dino: Compositing has perf benefits with massive complexity
04:30:05 [fantasai]
dino: Makes it harder to add useful things like blending
04:30:36 [fantasai]
krit says something
04:31:50 [fantasai]
dino: If you don't add the feature, people assume it's not there.
04:32:28 [fantasai]
dino: For widows and orphans, couldn't implement initial value of 2 because people assumed there was no widow/orphan control
04:32:42 [fantasai]
dbaron: I don't think there's been enough review of this to say "yes this is good right now"
04:32:47 [fantasai]
cabanier: I would love more reviews
04:33:00 [fantasai]
dbaron: Review isn't magical that ppl can just do, there are problems you don't find until you try to implement
04:33:37 [fantasai]
dbaron: and others that you don't find until you have two implementations and realize they're not interoperable
04:33:49 [fantasai]
dbaron: I'm concerned also about use cases, and if this is addressing things authors really want t do.
04:33:59 [fantasai]
dbaron: But don't know how to find out if that's the case.
04:34:07 [fantasai]
cabanier: Designers use it all the time in Adobe products
04:34:33 [fantasai]
dbaron: Other thing is, there is a trade-off here. Doing it once in Photoshop uses a lot less energy overall than sending it off to everyone's web browser.
04:34:48 [fantasai]
cabanier: Not replacing photoshop
04:34:58 [fantasai]
cabanier: But better to keep semantics than rasterizing
04:35:06 [fantasai]
dbaron: Anything else to discuss?
04:35:22 [fantasai]
cabanier: Don't think so
04:35:34 [fantasai]
dbaron: No objections now, but def want more time for ppl to look at this.
04:35:47 [fantasai]
cabanier: Testing feature behind flags
04:36:00 [fantasai]
fantasai: Do we need a new WD?
04:37:14 [fantasai]
04:37:59 [cabanier]
cabanier has joined #css
04:38:31 [fantasai]
Topic: min-zoom/max-zoom
04:38:40 [dbaron]
Topic: min-zoom/max-zoom media queries
04:38:48 [fantasai]
fantasai: Isn't the point of zoom to magnify things?
04:38:58 [fantasai]
heycam: Some people using mapping content using SVG
04:39:10 [fantasai]
heycam: want to do some kind of detail control
04:39:39 [fantasai]
heycam: Suggested this would be something to handle via Media Queries
04:40:14 [fantasai]
heycam: Situation is some iframes, several levels deep, want to know the zoom level of this map tile
04:40:35 [fantasai]
heycam: Came back with proposal where you have min-zoom/max-zoom, which is the resulting scale factor from natural size of the thing
04:41:08 [fantasai]
heycam: e.g. have SVG image shown at 50% of intrinsic size
04:41:32 [fantasai]
Bert, dbaron: resolution/device-pixel-ratio ?
04:42:03 [jet]
jet has joined #css
04:42:22 [fantasai]
heycam: Does that tell you that inner view is drawn at 4px per 1px of outer view?
04:42:29 [fantasai]
dbaron: Wrt device pixels
04:42:39 [fantasai]
heycam: ... See if that's what they need
04:43:04 [fantasai]
fantasai: it tells you the resolution
04:43:19 [fantasai]
fantasai: in device pixels per 'px', or 'in', or whatever
04:44:32 [fantasai]
heycam: asks for clarifications
04:44:51 [fantasai]
dbaron: It should work. Whether actually works in current implementations, might be a different
04:45:21 [dbaron]
Need to clarify behavior of 'resolution' media queries under transforms, especially if transforms non-axis-aligned
04:45:41 [fantasai]
fantasai: I would say, no, transforms don't affect media queries
04:45:49 [dbaron]
...but does viewBox?
04:45:52 [fantasai]
dbaron: But resizing due to change in viewbox would
04:46:25 [fantasai]
dbaron: I don't know that the spec is clearly enough defined to answer all these questions. Probably should be.
04:46:50 [fantasai]
dbaron: As an implementor, just went with "this is reasonable, sort of agrees with other browsers, good enough for ths week". But probably need to sort out this mess.
04:47:10 [dbaron]
... and how it responds to desktop browser zoom, and mobile browser zoom
04:47:17 [fantasai]
dbaron: e.g. how does browser zoom ui work, particularly desktop vs. mobile, which have different concepts of zoom
04:47:32 [fantasai]
krit: Designers want to have different details depending on zoom level
04:47:35 [dbaron]
heycam: so if 'resolution' doesnt account for intermediate transforms, how amenable would you be to having one that does?
04:47:36 [fantasai]
?: animation
04:48:05 [Cyril]
s/?: animation/cabanier: what about animations?/
04:48:15 [fantasai]
heycam: If what you want to do is to turn on some detailed element at some zoom level, and you're animating the size of the thing, I imagine that's what you'd want to happen
04:48:25 [fantasai]
heycam: So maybe I go back to talk about whether resolution should work or not
04:48:36 [fantasai]
glazou: David, you said that resolution, same thing
04:48:57 [fantasai]
glazou: I think dealing with resolution will be extremely tricky for some Web designer, and dealing with number for min-zoom /max-zoom, would be much easier
04:49:25 [fantasai]
heycam: Yeah, author would want to say "here's how content looks at default size; at twice maginification, looks like this"
04:49:51 [fantasai]
glazou: Wrt transforms scaling, ok, you can do that, but in simple case of normal web page where user just pinches, want to show control of whether it's zoomed in or not, don't think resolution provides a good solution
04:50:07 [fantasai]
glazou: You can't distinguish between iPad Retina and tablet with zooming
04:50:58 [fantasai]
dbaron: Mobile browser zoom doesn't affect media queries, whereas desktop does
04:51:09 [fantasai]
dbaron: I agree with everything you said, glazou, but I also want to avoid duplication.
04:51:20 [fantasai]
dbaron: Think we need to be clear on all these things before adding more to thiem
04:51:24 [fantasai]
04:51:42 [Zakim]
ok, dbaron; conference Team_(css)04:51Z scheduled with code 26631 (CONF1) for 180 minutes until 0751Z
04:52:36 [Zakim]
Team_(css)04:51Z has now started
04:52:43 [Zakim]
04:52:50 [fantasai]
fantasai: There are basically two types of scaling, graphical and logical.
04:52:55 [jdaggett]
zakim, ipcaller is me
04:52:55 [Zakim]
+jdaggett; got it
04:53:07 [fantasai]
fantasai: Sometimes you're just wnating to magnify what exists. Certain types of UI zoom, and transforms, fall into this category
04:53:25 [fantasai]
fantasai: Other times actually changing parameters of layout
04:53:35 [fantasai]
fantasai: Need to be clear on which effects go in which category.
04:54:26 [liam]
liam has joined #css
04:54:28 [fantasai]
glazou: Zooming by user is a user constraint; zooming by author is an author constraint
04:54:35 [fantasai]
glazou: First one makes sense for zoom, second for resolution
04:54:45 [Zakim]
04:54:55 [fantasai]
SimonSapin: What I think you mean is, the ration between the intrinsic size of an image and the used size of the image element in the outer document
04:55:31 [cabanier]
cabanier has joined #css
04:56:18 [shans__]
jdaggett: that was me, just setting things up.
04:56:37 [fantasai]
SimonSapin: This does not account for transforms
04:56:37 [cabanier]
cabanier has joined #css
04:56:56 [cabanier]
cabanier has joined #css
04:57:16 [fantasai]
dbaron: Might need another editor of MQ 4
04:57:28 [fantasai]
glazou: Florian is very busy right now, will have more time in a few months
04:57:34 [fantasai]
dbaron: Two big categories of changes
04:57:40 [fantasai]
dbaron: that need to happen
04:57:47 [fantasai]
dbaron: We talked very briefly of doing syntax changes
04:57:51 [fantasai]
dbaron: To be closer to @supports
04:58:03 [fantasai]
dbaron: Other was adding queries to represent everything in media types, deprecating media types
04:58:07 [fantasai]
dbaron: But those ar ebiger things
04:58:19 [krit]
04:59:14 [fantasai]
s/ar ebiger/are bigger/
04:59:49 [fantasai]
krit: Security question wrt basic shape
04:59:58 [fantasai]
krit: Can use CSS shapes to define a clipping area
05:00:08 [fantasai]
krit: Here's an image, can define a clip path on it.
05:00:14 [fantasai]
krit: Can also be animated
05:00:20 [fantasai]
krit: Quite easy to apply this clip path
05:00:28 [fantasai]
krit: Problem is the following
05:00:45 [fantasai]
krit: Usually you have clip-path inline in your style sheet
05:00:55 [fantasai]
krit: Can also cross-reference path from a different domain
05:01:07 [fantasai]
krit: Suppose, e.g. style sheet on
05:01:17 [fantasai]
krit: tries to reference it
05:01:30 [fantasai]
krit: question is, can any private data come from this style sheet
05:01:37 [fantasai]
krit: ... pointer events
05:01:50 [fantasai]
krit: If you cliip to circle, outside that doesn't contribute to clipping area
05:01:59 [fantasai]
krit: Suppose one domain uses clip path to show password or something
05:02:22 [fantasai]
krit: If you clip anything with this letter here, then the areas outside it don't contribut to hit testing
05:02:35 [fantasai]
krit: So could scan the clipping path and reingineer what the clip-path could look like
05:02:49 [fantasai]
dbaron: I think anyone using clip-path to use confidential data is doing it wrong.
05:02:57 [fantasai]
dbaron: If that's the attack, I'm not that worred about it!
05:03:31 [fantasai]
dbaron: I would be more worried about an attack that involved treating other data as pieces of a CSS style sheet
05:03:43 [fantasai]
dbaron: e.g. send someone an email message with some CSS in the subject
05:03:59 [fantasai]
dbaron: And then closing equivalent to that in another message
05:04:14 [fantasai]
dbaron: Could retrieve all the subjects in between by requesting a particular URL from Yahoo.
05:04:20 [fantasai]
dbaron: That I'd be worried about
05:04:28 [fantasai]
dbaron: But this I'm not worried about
05:05:27 [fantasai]
glazou: I'm not that worried...
05:05:36 [fantasai]
Alan asks about some other shape image thing
05:05:50 [fantasai]
krit: Very weird case. Only one I could come up with as an issue
05:06:06 [fantasai]
heycam: What if you had a style sheet that just had content property, did hit testing on content
05:06:19 [fantasai]
krit: That would be a bigger security issue.
05:06:48 [fantasai]
fantasai: Putting sensitive data in a style sheet's content property also makes no sense at all.
05:08:09 [fantasai]
heycam discusses other ways of exposing things in the same way
05:08:15 [lmclister]
lmclister has joined #css
05:08:16 [fantasai]
s/ways of/properties/
05:09:20 [fantasai]
05:10:08 [fantasai]
krit: If we agree this is a security problem, then our options are to remove [...]
05:10:09 [heycam]
My point is if you can show that you can already get some information by testing an element styled by a style sheet from another domain -- e.g. the content property -- then it's fine to have shapes in clip-path, since it's not opening the hole any further.
05:10:20 [fantasai]
dbaron: I think we pretty much agree that it's not a security problem we want to fix.
05:10:34 [fantasai]
dbaron: We could put a note in the spec, that authors shouldn't put sensitive info in clip path
05:10:34 [dbaron]
(unless there's a worse case that we haven't heard yet)
05:10:54 [fantasai]
Alan, heycam: Don't think this is an issue
05:11:02 [heycam]
05:11:51 [fantasai]
Bert: Position div for each pixel of your password
05:11:52 [dbaron]
05:11:57 [fantasai]
dino: I don't know why we're even discussing this.
05:12:10 [fantasai]
Bert: Good to discuss, but I think we can conclude that this is a weird case we don't need to worry about
05:12:42 [fantasai]
RESOLVED: We don't care, unless bz can come up with something more convincing
05:13:44 [fantasai]
Topic: SVG text-wrapping
05:13:58 [fantasai]
tav: Things we would most need from Exclusions and Shapes have been removed from latest drafts
05:14:12 [fantasai]
tav: shape-inside
05:14:17 [fantasai]
tav: And using SVG paths and shapes
05:14:24 [fantasai]
Alan: My plan for that is to have that in next level of CSS Shapes
05:14:45 [fantasai]
Alan: I'm trying to constrain first level of spec ot stuff that is most immediately useful to CSS at the moment
05:15:02 [fantasai]
Alan: I don't think there's an issue with having your SVG work depend on Shapes level 2 instead of Shapes level 1
05:15:15 [fantasai]
glazou: Problem is referencing a non-normative document
05:15:53 [krit]
krit has left #css
05:15:58 [fantasai]
glazou: Discusison in AC forum, W3C suggested references can only be W3C RECs. Document referencing WD can't go to REC
05:16:05 [krit]
krit has joined #css
05:16:08 [fantasai]
plh: But can go to PR. Just can't go to REC.
05:16:40 [fantasai]
fantasai: I don't think this will be an issue
05:16:56 [fantasai]
plh: For the record, Robin Berjon started a thread on chairs list wrt dependencies
05:17:06 [fantasai]
Alan: Noted, haven't created L2 document yet
05:17:46 [fantasai]
Alan: question of whether to make L2 doc to park these things in
05:18:05 [fantasai]
TabAtkins: Make ssense. Just put <details class=obsolete> and note things
05:18:07 [dbaron]
So I think Boris's concerns in that thread are actually somewhat different from that contrived bank case.
05:18:09 [fantasai]
TabAtkins: Maybe I'll rename the class
05:18:26 [dbaron]
maybe more like
05:19:01 [fantasai]
Topic: security
05:19:38 [fantasai]
dbaron: Involves using clip-path on attacker site over <iframe> to victime site.
05:19:50 [fantasai]
dbaron: That's more concerning.
05:20:00 [fantasai]
dbaron: But not useful to discuss here.
05:20:10 [fantasai]
dino: How is it more of a problem than overflow?
05:20:12 [fantasai]
dbaron: Not different.
05:20:18 [dbaron]
message from roc:
05:20:26 [fantasai]
krit: [stuff]
05:21:23 [fantasai]
dbaron: The attack I described wasn't what bz described
05:21:38 [fantasai]
dbaron: This is stuff that needs to be thought about longer. We should be fine, I think.
05:22:04 [dbaron]
... since bz was describing something that would be fixed by rejecting clip-path for cross-origin non-CORS style sheets
05:22:08 [fantasai]
heycam: been awhile since roc's message. should someone look at that?
05:22:27 [dbaron]
which the attack of a site that controls a site's cross-origin style sheet and can simultaneously frame it doesn't cover
05:22:47 [dbaron]
s/doesn't cover/isn't fixed by/
05:23:33 [fantasai]
Topic: Figuring out the CSSWG agenda
05:23:56 [glazou]
05:24:24 [r12a]
r12a has joined #css
05:24:26 [krit]
s/[stuff]/Boris is referencing a mail of roc. The problem that roc's describing has to do with feDisplacementMap that is based on pixel displacement by color value. In combination with the current defintion of 'pointer-events', it can influence hit testing in a way that it can be used to reveal privacy data./
05:26:55 [krit]
krit has left #css
05:26:59 [krit]
krit has joined #css
05:34:34 [shige_]
shige_ has joined #css
05:43:29 [r12a]
05:44:25 [dbaron]
05:44:43 [dbaron]
there's one issue listed in
05:45:00 [dbaron]
Topic(a few lines back): Counter Styles
05:46:50 [myakura]
r12a, I see some Japanese counter styles in the Hebrew section...
05:47:35 [fantasai]
Discussion of whether to publish Counter Styles as LC
05:47:47 [dbaron]
want to link to r12a's document, which is to be published as a note
05:47:49 [fantasai]
Richard posts the i18n note wrt @counter-style rules for various scripts
05:47:58 [dbaron]
glazou: should we give people a few weeks to review
05:48:01 [dbaron]
fantasai: we already did that
05:48:38 [dbaron]
I'm fine with going to LC, though I'm really not sure how high of an implementation priority this is for anyone.
05:49:13 [fantasai]
05:49:30 [dbaron]
... css-counter-styles-3 to Last Call, ask for review from HTML, i18n, ... oh, wait, we resolved to go to LC last week
05:50:46 [TabAtkins]
05:50:49 [fantasai]
ScribeNick: fantasai
05:51:12 [fantasai]
TabAtkins: This is in section describing how levels of things are handled
05:51:21 [fantasai]
TabAtkins: We inserted Scope in the middle here
05:51:30 [fantasai]
TabAtkins: Scoped style sheets always win over unscoped styles
05:51:39 [fantasai]
TabAtkins: Scoping something further down in the document overrides coping rules further up i nthe document
05:51:53 [fantasai]
TabAtkins: Question is , does this sound sufficient for a spec defining this?
05:51:57 [fantasai]
TabAtkins: Think it is correct
05:52:25 [fantasai]
fantasai: By default, inner scopes win over outer scopes
05:52:40 [fantasai]
fantasai: But for !important rules, order is reversed
05:52:42 [Rossen]
Rossen has joined #css
05:53:00 [fantasai]
fantasai: Outer !important rules override inner !important
05:53:55 [fantasai]
dbaron: Other alternative is for inner !important to win over outer !important
05:54:15 [fantasai]
heycam: I think the current spec is a nice parallel with how origins work
05:54:58 [fantasai]
fantasai: I think this gives !important a useful purpose in negotiating rules between inner and outer scopes
05:55:09 [fantasai]
fantasai: So somewhat prefer this behavior
05:55:22 [fantasai]
TabAtkins: Seems from heycam that the spec is clear enough
05:55:54 [fantasai]
Bert: Why have scopes be special, why not have it same as ID selector
05:55:59 [fantasai]
glazou: I proposed that several times, was turned down
05:56:48 [fantasai]
dbaron: Not the same is because you want rule in inner scope to beat rules in outer scope, and if you treat them as both +ID, they will intermingle
05:56:55 [fantasai]
Bert: That's what I expect
05:56:58 [fantasai]
dbaron: That's not what authors expect
05:57:17 [fantasai]
TabAtkins: Point is that scoped rules apply only to your bit, and can have short, simple selectors
05:57:27 [fantasai]
TabAtkins: Lends itself to lower-specificity selectors
05:57:47 [fantasai]
TabAtkins: Rules that apply to whole document tend to be more verbose, more specific
05:58:00 [fantasai]
TabAtkins: Want the simpler scoped rules to still override document-wide, more-specific rules
05:58:26 [fantasai]
Bert: But adding new concept
05:58:40 [fantasai]
glazou: It's equivalent to adding a 4th argument to specificity
05:58:54 [fantasai]
05:59:24 [fantasai]
Bert: { blue } vs. scoped span { green }
05:59:39 [fantasai]
Bert: Expect <> to be blue, not gree.
05:59:44 [fantasai]
dbaron: Expect it to be green
05:59:47 [fantasai]
06:00:49 [fantasai]
glazou: Last time we discussed this, the painful bit was only adding dynamically adding styles [?]
06:01:10 [fantasai]
TabAtkins: From author feedback over long period of time, because specifying things defined in HTML for awhile, this was the most intuitive behavior for authors
06:01:19 [fantasai]
plh: Not implemented though, so haven't played with it.
06:02:55 [fantasai]
RESOLVED: Close issue on how !important interplays with scoped styles
06:03:06 [glazou]
<br type="break"/>
06:22:19 [tobie]
tobie has joined #css
06:23:13 [TabAtkins]
Cyril: Thanks!
06:27:15 [fantasai]
jdaggett, plinss, r12a won't be here tomorrow afternoon, so maybe move charter/font-loading/principles to afternoon, and pull CSS3 Text/Text-Decoration forward into the morning?
06:28:29 [jdaggett]
fantasai: i actually don't think we'll be able to deal with fonts/text/text-decoration all in the morning
06:28:47 [AndChat|474201]
AndChat|474201 has joined #css
06:28:47 [jdaggett]
fantasai: guess we can try though
06:29:20 [fantasai]
TabAtkins: Continuing with 'default' keyword
06:29:37 [jdaggett]
reference url?
06:29:53 [jerenkrantz]
06:30:33 [fantasai]
dbaron: I had initially proposed default as something else, as initial/inherit. Still would like that behavior.
06:30:48 [fantasai]
TabAtkins: The reason I don't want to do that, doesn't do what authors want
06:31:19 [Zakim]
06:31:32 [jdaggett]
um, phone dropped
06:31:39 [myakura]
myakura has joined #css
06:31:49 [jdaggett]
shans__: ^
06:31:52 [fantasai]
TabAtkins: E.g. want "default" to mean "display: block/inline" depending on whether <p> or <span>
06:31:54 [dbaron]
jdaggett, ack
06:32:06 [fantasai]
dbaron: Not always. E.g. reset stylesheets want my behavior
06:32:11 [dbaron]
jdaggett, apparently it's because shane left
06:32:12 [fantasai]
TabAtkins: Don't think we need to cater to reset style sheets
06:32:13 [jdaggett]
dbaron: you guys dropped off the call!!
06:32:15 [jdaggett]
06:32:16 [Rossen]
Rossen has joined #css
06:32:33 [nikos]
nikos has joined #css
06:32:37 [dbaron]
jdaggett, apparently it requires a computer that can get on the corp network, which tab's can't
06:32:38 [fantasai]
fantasai: Could add special ability to 'all' shorthand
06:33:19 [fantasai]
dbaron: The other issue with this definition of default is that it's a decent amount of work to implement
06:33:28 [fantasai]
TabAtkins: Won't disagree with that
06:33:38 [fantasai]
SimonSapin: Think it requires keeping around multiple specified values
06:34:00 [shans___]
shans___ has joined #css
06:34:02 [fantasai]
TabAtkins: Don't have to keep things around, just might need multiple passes, and just for elements it shows up on
06:34:11 [fantasai]
SimonSapin: Isn't that similar perf cost with variables?
06:34:11 [shans___]
what is the zakim bridge conference id?
06:34:17 [fantasai]
dbaron: It can be done without that perf cost
06:34:19 [jdaggett]
06:35:06 [dbaron]
"This passcode is not valid."
06:35:19 [plinss]
zakim, code?
06:35:19 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200, plinss
06:35:40 [shans___]
need a new one
06:35:53 [Zakim]
06:35:55 [Zakim]
Team_(css)04:51Z has ended
06:35:55 [Zakim]
Attendees were jdaggett, Meeting_Room
06:36:07 [dbaron]
Zakim, room for 5 for 150 minutes?
06:36:08 [Zakim]
ok, dbaron; conference Team_(css)06:36Z scheduled with code 26632 (CONF2) for 150 minutes until 0906Z
06:36:31 [dbaron]
shans___, ^
06:36:38 [Zakim]
Team_(css)06:36Z has now started
06:36:48 [Zakim]
06:36:52 [jdaggett]
zakim, ipcaller is me
06:36:52 [Zakim]
+jdaggett; got it
06:37:35 [zcorpan]
zcorpan has joined #css
06:37:44 [dbaron]
"This passcode is not valid."
06:37:58 [Zakim]
06:37:58 [zcorpan]
zcorpan has joined #css
06:38:03 [dbaron]
Zakim, ??P1 is Meeting_Room
06:38:03 [Zakim]
+Meeting_Room; got it
06:38:13 [jdaggett]
ok, good good
06:38:19 [jdaggett]
06:38:34 [jdaggett]
default was the topic...?
06:38:59 [jerenkrantz]
jdaggett: yes
06:38:59 [fantasai]
TabAtkins: I don't really want initial-or-inherit. No use case for it
06:39:06 [glazou]
jdaggett, yes
06:39:06 [fantasai]
dbaron: Use it internally a lot
06:39:17 [fantasai]
dbaron: e.g. Web Components style reset
06:39:31 [fantasai]
dbaron: Think that basically is equivalent to all:initial-or-inherit
06:40:01 [fantasai]
TabAtkins: Given that those don't have any UA style rules anyway... I think that's equivalent to 'default'
06:40:55 [Ms2ger]
Ms2ger has joined #css
06:41:18 [fantasai]
heycam: want s/continues/repeats/ ?
06:41:43 [fantasai]
TabAtkins clarifies what default does
06:41:58 [fantasai]
ACTION TabAtkins clarify what default does
06:41:58 [trackbot]
Error finding 'TabAtkins'. You can review and register nicknames at <>.
06:42:26 [Zakim]
06:43:00 [fantasai]
dbaron: Putting !important and normal together makes it harder to implement
06:44:01 [jdaggett]
argh, back in a sec
06:44:31 [fantasai]
dbaron: Implementation I would take would do the wrong thing for user !important and ua !important
06:44:59 [fantasai]
dbaron: Current spec, user !important rule says go use the author styles
06:45:09 [fantasai]
dbaron: But if no author styles, don't use user styles
06:45:19 [fantasai]
TabAtkins: No, no, we only glom together all the author styles.
06:45:33 [fantasai]
TabAtkins: You still keep user as an origin level
06:45:48 [Zakim]
06:46:08 [jdaggett]
zakim, ipcaller is me
06:46:08 [Zakim]
+jdaggett; got it
06:46:30 [fantasai]
dbaron: Ok, that's fine
06:46:33 [fantasai]
dbaron: But make it clearer
06:46:53 [fantasai]
fantasai: We could put in a simplified cascade list, just to make it more obvious
06:47:39 [fantasai]
fantasai: Any other concerns with default?
06:47:47 [fantasai]
fantasai: Do we want an initial-or-inherit keyword?
06:48:08 [fantasai]
TabAtkins: I suggest using actually 'initial-or-inherit'. Want to steer authors to 'default', since that's usually the right answer.
06:48:29 [fantasai]
dbaron: Would like to see a keyword for that
06:48:40 [fantasai]
Bert: Would like to understand better what this is used for
06:49:04 [fantasai]
TabAtkins: You use it in most use cases for dbaron's examples, except this is the better answer in most cases
06:49:54 [fantasai]
TabAtkins: For a use case, sometimes it's much easier to create positive selectors than :not() selectors, and wipe out what you had before
06:50:08 [fantasai]
TabAtkins: Point is to wipe out whatever author has done
06:50:17 [fantasai]
TabAtkins: This is better because it respects user styles
06:50:46 [fantasai]
TabAtkins: And UA styles
06:51:03 [fantasai]
TabAtkins: Most authors don't understand difference between initial value and UA default value
06:51:11 [fantasai]
TabAtkins: This lets you not worry about that
06:51:29 [shige-o]
shige-o has joined #css
06:52:33 [fantasai]
06:53:05 [fantasai]
plinss: This removes your rules.
06:53:19 [fantasai]
TabAtkins: Not sure whta you're objecting to, what you're asking for is exactly what this does.
06:53:30 [fantasai]
Bert: You said it's easy to specify a generic rule, and override a specific case
06:53:52 [fantasai]
Bert: span { color: green; } { color: default; }
06:53:55 [fantasai]
Bert: Then I get inherited
06:54:14 [fantasai]
TabAtkins: That's what you get, unless user or UA says something
06:54:32 [fantasai]
TabAtkins: Let me show different example
06:54:39 [fantasai]
TabAtkins: User says wants links are bright blue
06:54:55 [fantasai]
TabAtkins: Author styles links purple, except some links with class should use default colors
06:55:09 [fantasai]
TabAtkins: If you use 'initial' or 'inherit' to wipe out author rules, the colors will reset to black.
06:55:21 [fantasai]
TabAtkins: Doesn't go back to blue.
06:55:39 [fantasai]
Bert: Why would I want user's rule
06:55:43 [fantasai]
Bert: I don't know what they are
06:55:46 [fantasai]
plinss: That's the point
06:56:23 [fantasai]
TabAtkins: This goes back to "whatever style would be without my influence"
06:56:38 [stakagi]
stakagi has joined #css
06:56:51 [fantasai]
Bert: Think examples would be good
06:58:12 [fantasai]
fantasai: Better example would be paragraphs. By default, have 1em margin on top and bottom.
06:58:34 [fantasai]
fantasai: If I styling thing, and want to go back to the default styling, would ask for 'default'. Gets ack to 1em margin.
06:58:55 [fantasai]
fantasai: If said 'initial', then would set margins to zero.
06:59:24 [fantasai]
Bert: i'm not convinced, but if you can get some examples in there, would help
06:59:47 [fantasai]
leaverou_away, Can you help here?
07:00:38 [fantasai]
RESOLVED: Ok with current definition of 'default', remove issue
07:00:44 [fantasai]
but also clarify the spec and add examples
07:01:41 [fantasai]
fantasai: Suggest inherit-or-initial
07:01:47 [fantasai]
plinss: reset?
07:01:53 [fantasai]
TabAtkins: Want it to be long an annoying
07:03:19 [Cyril]
07:03:33 [fantasai]
TabAtkins: Using 'default' for this because already reserved, and does more or less what was intended for that value.
07:03:54 [fantasai]
Cyril: Question wrt inheritance
07:04:01 [fantasai]
Cyril: First paragraph, 2nd sentence
07:05:05 [glazou]
Bert, ok but unsure at this time
07:05:06 [fantasai]
[... wordsmithing ...]
07:06:22 [dbaron]
"unless the cascade results in a value" -> "when the cascade does not result in a value"
07:06:50 [Cyril]
07:07:30 [fantasai]
Topic: Cascading of Transitions and Animations
07:07:50 [stearns]
07:07:51 [fantasai]
TabAtkins: Order in css3-cascade matches Gecko behavior. Apparently WebKit's behavior can't be explained in terms of cascade
07:08:03 [dbaron]
07:08:16 [dino]
dino has joined #css
07:08:40 [fantasai]
dbaron: There were pieces of each behavior that was considered crazy and unimplementable
07:08:58 [fantasai]
dbaron: Made progress towards acceptable behavior for this during special meeting
07:09:07 [fantasai]
dbaron: Wrote up in this message, which I have long since forgotten
07:09:30 [fantasai]
dbaron: This message actually has transitions at a different point in the cascade, but agrees with cascade wrt animations
07:10:13 [fantasai]
fantasai: Does this mean that you can never transition !important values/
07:10:27 [fantasai]
dbaron: It means that if you change something to !important, it will not transition
07:10:44 [fantasai]
dbaron: But if you change something from !important, might get a transition
07:10:58 [fantasai]
fantasai: What if both are !important?
07:11:03 [fantasai]
dbaron: No transition
07:11:30 [fantasai]
fantasai: Don't like that.
07:12:40 [fantasai]
dbaron: We all agreed that we want animations to override transitions, and that we want !important to override animations, and
07:13:10 [fantasai]
dbaron: now proposing that transitions override !important rules
07:13:24 [fantasai]
plinss: I think in Lyon we talked about animations not causing transitions
07:14:16 [fantasai]
shane: I don't think we're asking that transitions override !important, just that they be able to transition
07:15:00 [fantasai]
fantasai: Think animations win over transitions because the two rules transitioning are lower
07:15:03 [SimonSapin]
07:15:07 [fantasai]
dbaron: Could introduce some magic
07:15:09 [jdaggett]
oh gawd, dbaron and fantasai and magic....
07:15:29 [fantasai]
dbaron: Could say that if you have an animation running, any transition rules for that property don't apply
07:15:47 [fantasai]
dbaron: Not sure that works, because we have to consider inheriting properties
07:15:55 [fantasai]
dino: I think in our discussion we got to that point and then gave up
07:16:02 [fantasai]
dbaron: Gave up on starting transitions
07:16:27 [fantasai]
TabAtkins: What is the inheritance problem? I shtat #3?
07:16:31 [fantasai]
07:16:47 [fantasai]
dbaron: Say you have animations/transitions on color
07:17:00 [fantasai]
dbaron: Have a currently running transition on the child, and start an animation on the parent
07:17:03 [fantasai]
dbaron: nevermind
07:17:09 [fantasai]
dbaron: Nothing in the cascade will help there; you just lose
07:17:42 [fantasai]
dbaron: transition will keep running on child, we're ok with that?
07:17:56 [fantasai]
TabAtkins: The effects of animations can never cause a transition, including inherited effects of animations
07:18:04 [fantasai]
plinss: Could ahve set value of child, that gets unset,
07:18:25 [fantasai]
plinss: And then goes back to inherited, but that value is animating
07:18:34 [fantasai]
dino: Bad example was parent and child with transition set up for color
07:18:38 [fantasai]
dino: But child has color inherit
07:18:55 [fantasai]
dino: You transition parent. What happens to child? When does its transition start?
07:19:04 [fantasai]
dbaron: What my proposal does for plinss's question...
07:19:07 [birtles]
birtles has joined #css
07:19:38 [fantasai]
dbaron: What the model I proposed does, if you have an override on the child that you remove such that you now inherit an animating value from the parent
07:20:16 [fantasai]
dbaron: This wouldn't produce a great result, would cause transition to go to animating value at the time the transition started, and when completed, would jump to wherever it would be
07:20:51 [fantasai]
dbaron: Model I was proposing is that mechanism by which we prevent animations from triggering transitions, when you decide whether to transition you look at animations as they are at the current time
07:20:58 [fantasai]
dbaron: So never comparing to animation at a different time
07:21:06 [r12a]
r12a has joined #css
07:21:17 [fantasai]
dbaron: So when there is a style change that is not animation-triggered, you need to get your animation style up-to-date first, before figuring out whether to start transitions
07:21:32 [fantasai]
dbaron: And that was a defined way of describing interaction between the two.
07:21:43 [fantasai]
fantasai: Have a question, may or may not make sense.
07:21:52 [fantasai]
fantasai: would it work to sovle the things we want
07:21:59 [fantasai]
fantasai: if we went with the cascade that's in gecko
07:22:15 [fantasai]
fantasai: But said that a transition never starts if the start state or the end state is an animation
07:22:28 [fantasai]
TabAtkins: Or is produced by an animation via inheritance.
07:22:46 [fantasai]
dbaron: Produced by animation via inheritance, say you have font-size animating, and width in em units
07:23:04 [fantasai]
dbaron: Tracking what's caused by an animation is very complex
07:23:09 [jerenkrantz]
RRSAgent: make minutes
07:23:09 [RRSAgent]
I have made the request to generate jerenkrantz
07:23:25 [fantasai]
plinss: Thing about this that bothers me
07:23:45 [fantasai]
plinss: Talking about a lot of edge cases, cause lots of discontiguous jumps when animations/transitions applied
07:23:53 [fantasai]
plinss: Understand some implementations may not be able to avoid jumps
07:24:00 [fantasai]
plinss: But certainly don't want to require them
07:24:28 [fantasai]
plinss: [...?]
07:24:46 [fantasai]
dbaron: One concern wrt that kind of thing, we tend to as a group want to gradually narrow possibilities
07:24:48 [shige-o]
shige-o has joined #css
07:25:02 [fantasai]
dbaron: But some of those gradual changes might trigger a rewrite in certain implementations
07:25:15 [fantasai]
plinss: Then get it right the first time
07:25:42 [fantasai]
dbaron: Need a description of what the right behavior is
07:25:52 [fantasai]
plinss: Transitions should always be smooth
07:26:01 [fantasai]
dbaron: start value and end value for transition
07:26:13 [fantasai]
dbaron: Are you ok with start value is always static, but end value might be animating
07:26:25 [fantasai]
fantasai: ?
07:26:36 [fantasai]
TabAtkins: Start state is something specific, end state is inherit
07:27:00 [fantasai]
TabAtkins: Parent was running a thing, and now inheriting animated value, so transitioning towards moving target
07:27:12 [fantasai]
TabAtkins: Are we ok with tranistioning towards a moving target
07:27:46 [fantasai]
dino describes WebKit's behavior, which is bad, which chains transitions together
07:29:40 [fantasai]
[discussion of this bug]
07:30:49 [dbaron]
you may recall from Tucson
07:32:31 [fantasai]
TabAtkins: I think I'd be ok with either dbaron's model where inherited animation or transition values don't kick off new transitions on the child, but do move endpoint of running transition
07:33:14 [fantasai]
TabAtkins: Or, I guess proper implementation of Dean's model, where they do continually kick off transitions, but values are only 1 frame apart in transition, so transition end won't be detectable
07:33:27 [fantasai]
dbaron: It's detectable due to TransitionEnd events
07:33:46 [fantasai]
Rossen: What you see as a user, you'll see color transition from green to blue (looking at point 7) over 2s
07:33:55 [fantasai]
Rossen: then detransitioning from blue to green over 10s
07:34:36 [fantasai]
07:35:14 [fantasai]
Rossen: so proposal was for #a and #b t transition over 2 and 10 s, respectively
07:36:18 [fantasai]
plinss: Would argue from user's perspective, bheavior that user expects is that #b will transition from green to blue over 10s
07:36:30 [fantasai]
plinss: at the same time #a is transitioning over 2s
07:36:44 [fantasai]
dbaron: There's another problem
07:36:52 [fantasai]
dbaron: I think user expectation is that whichver time is longer wins
07:37:05 [fantasai]
dbaron: If you swap the times, especially when one is unnoticeable
07:37:20 [fantasai]
plinss: I think if you swap the times, user will expect #a to transition over 10s and #b over 2s
07:37:38 [fantasai]
plinss: IMO #b's behavior should not change based on whether #a has a transition or not
07:38:22 [fantasai]
dbaron: Other way to frame problem, don't want a discontinuity between no transition at all vs. very short transition (e.g. 10ms), that lasts longer than 10ms
07:39:03 [fantasai]
rossen: Transitioning independently
07:39:10 [fantasai]
dbaron: What if you swap times and put longer time outside?
07:39:13 [fantasai]
plinss: irrelevant
07:39:25 [fantasai]
dbaron: The thing is, default for transition not happening is time is zero
07:39:43 [fantasai]
dbaron: The only thing that makes the transition happen is the time
07:40:09 [fantasai]
dbaron: If #a has a long transition and you change from #b from 0s to 10ms, that drastically cuts the time of #b's transition
07:40:42 [fantasai]
dbaron: Rules could come from different parts of cascade, e.g. box and button iside box, designed to have independent transitions
07:41:02 [fantasai]
jdovey: [...]
07:41:14 [fantasai]
TabAtkins: I think your model works for this, dbaron
07:41:20 [fantasai]
dbaron: No, don't yet know of a model that works for this
07:41:48 [AndChat|474201]
AndChat|474201 has joined #css
07:41:56 [fantasai]
TabAtkins: his model is if you inherit a value from your parent, and that value is produced by transition or animation, it will not start transition, but existing transition will still update its endpoint to that value
07:42:01 [fantasai]
TabAtkins: ... no, won't start. Nevermind
07:42:12 [fantasai]
dbaron: When I proposed that, just thought of it for animations, not transitions
07:42:23 [fantasai]
dbaron: if you start applying to transitions, too...
07:42:56 [fantasai]
TabAtkins: A change from a static value to an animating value, will kick off a transition
07:43:06 [fantasai]
dbaron: you don't have that info
07:43:47 [fantasai]
07:44:03 [fantasai]
plinss: In this example, when you start/stop hovering, both transitions start imultaneously
07:44:09 [fantasai]
plinss: The short transition will have end point of blue
07:44:20 [fantasai]
plinss: And long transitions endpoint, over first 2s, will transition from green to blue
07:44:42 [fantasai]
TabAtkins: In order to say endpoint is changing, have to know that endpoint is coming from transition
07:44:57 [fantasai]
TabAtkins: But that's not updating endpoint, it's resetting transition counter
07:45:14 [rhauck]
rhauck has joined #css
07:45:46 [fantasai]
plinss: Don't need complex data flow analysis. Just tag all the transitions [...]
07:46:19 [fantasai]
dbaron: If you're kicking off multiple transitions at the same time, need to recompute style twice for each transition you're kicking off, possibly for entire subtree
07:46:27 [fantasai]
plinss: Problem is transitioning for somethign changed via inheritance
07:46:44 [fantasai]
plinss: Because you're inheriting result of a transition
07:47:15 [fantasai]
dino: Similar problem with width in ems
07:47:22 [fantasai]
TabAtkins: Can't just track inheritance
07:48:23 [fantasai]
07:48:35 [fantasai]
TabAtkins: Think reasonable model is that every single computed value change triggers transition
07:48:41 [fantasai]
plinss: So I have clarification ...
07:48:42 [shige-o]
shige-o has joined #css
07:48:56 [fantasai]
plinss: If in this case, the font-size #b does not have a transition on it
07:49:02 [fantasai]
plinss: #c has transition on width.
07:49:07 [fantasai]
plinss: Is width going to transition?
07:49:09 [fantasai]
dbaron: Yes
07:49:28 [fantasai]
plinss: The 10ems didn't change
07:49:33 [fantasai]
plinss: the specified value didn't change
07:49:48 [fantasai]
fantasai: transitions are based on computed value
07:50:03 [fantasai]
dbaron: This is the list of testcases that I proposed we not care about
07:50:14 [AndChat|474201]
AndChat|474201 has joined #css
07:50:36 [Cyril]
equivalent example in SVG:
07:50:41 [fantasai]
dbaron: Meaning, some of these will do weird things, and authors will just get what they deserve
07:51:26 [fantasai]
TabAtkins: ...
07:51:32 [fantasai]
TabAtkins: So we have the 3-way override with magic to make it all work
07:52:15 [TabAtkins]
s/.../So we go back to the earlier idea: use the cascade origins as defined, but say that a running animation turns off transitions on the affected properties./
07:57:13 [fantasai]
TabAtkins: If you :hover an element, and that starts an animation, and the animations' first value is different from the old value, will trigger a transition
07:57:28 [fantasai]
TabAtkins: Which, if it's shorter than the animation, will be hidden by animation (but not otherwise)
07:57:49 [jdaggett]
is rossen saying anything important?
07:58:05 [jdaggett]
he's ....far.... away from the mic
07:58:11 [jdaggett]
07:58:12 [fantasai]
Rossen: In all of these cases, when transition is longer than the animation, the end tail of the transition [...] almost hte same value, so visually in lock-step with animation
07:58:27 [fantasai]
dino: Think point B is significant change from WebKit
07:58:41 [fantasai]
dbaron: Was just proposing to modify point B with magic
07:58:50 [fantasai]
TabAtkins: With animations turns off transitions magic?
07:58:57 [fantasai]
dbaron: Sounded like what we're moving towards
07:59:13 [fantasai]
dbaron: B would then be what Cascade then has
07:59:34 [fantasai]
TabAtkins: If transition is kicked off on different property via computed value linkage, will still trigger transition.
07:59:43 [fantasai]
TabAtkins: Something will happen, will be well-defined answer, but we don't care what happens
07:59:54 [fantasai]
dino: And authors will be so confused, they won't know what went on
08:00:56 [fantasai]
TabAtkins: Proposal is Adopt A, C, E, and D, and use cascade's ordering plus animations turn off corresponding transitions magic
08:01:08 [fantasai]
fantasai: I *think* that sounds alright
08:01:40 [fantasai]
plinss: That precludes a lot of situations we might want, like transitioning to an animated state
08:02:10 [fantasai]
fantasai: We talked about that in Lyon, and I was convinced we don't want to tackle that right now, because we don't have rate-based transitions
08:02:41 [fantasai]
fantasai: And getting those kinds of transitions to work well requires more sophisticated tools than just time-based transitions
08:02:58 [fantasai]
fantasai: I think that's something we could add later, maybe with an 'animation-transition' property or something. :)
08:03:25 [fantasai]
dino: David, when do you think you'll start testing this?
08:03:27 [fantasai]
dbaron: No idea
08:03:38 [fantasai]
TabAtkins: Shane, you said Blink's changing animation stuff?
08:03:49 [fantasai]
TabAtkins: Oh, well why don't you implement this?
08:04:07 [fantasai]
shane: I'd say, I'd be surprised if we didn't have something by the next F2F meeting
08:04:16 [fantasai]
TabAtkins: So plan for Paris to have feedback from us
08:05:03 [fantasai]
shane: Some concern wrt changing behavior, but does seem to be fairly edge cases.
08:05:49 [fantasai]
dbaron: A bunch of this requires edits to Transitions, particularly to places where spec is very vague
08:05:55 [fantasai]
dbaron: If we resolve on this, I'd make those edits
08:06:11 [fantasai]
Proposal: Resolve on those edits, then re-evalueate after implementation experience
08:07:11 [fantasai]
RESOLVED: Adopt A, C, D, and E from <>, cascade as specified in css3-cascade, plus magic: animation on an element turns off transitions for the affected properties. Re-evaluate after implementation experience.
08:07:30 [fantasai]
dbaron: For Transitions, only one other issue. Tab has had an action to write a demo for last few F2Fs.
08:07:43 [fantasai]
TabAtkins: Ok, I will make a demo tonight!
08:08:00 [fantasai]
plinss discusses CR strategy
08:08:38 [fantasai]
plinss: I'm happy to go to CR with our best guess of what we think will stick. We can bounce back to LC to fix things. Implementation experience is what CR is for.
08:08:50 [fantasai]
dbaron: Would write several screenfuls of At-Risk text
08:08:53 [fantasai]
dbaron: But ok
08:09:14 [fantasai]
plinss: Would like to leave this F2F with both specs going to LC
08:09:29 [fantasai]
TabAtkins: Ok, so this means no change to Cascade.
08:09:38 [fantasai]
TabAtkins: Which closes all the issues on Cascade.
08:09:41 [dbaron]
I'm happy moving cascade to LC.
08:09:47 [fantasai]
TabAtkins: How do people feel about going to LC?
08:10:43 [fantasai]
RESOLVED: Take CSS3 Cascade to LC, with edits mentioned in minutes today.
08:11:45 [fantasai]
ping HTMLWG especially, also notify WebApps, SVG, WAI
08:12:03 [fantasai]
4 weeks LC period
08:13:57 [fantasai]
Cyril notes an inconsistency in the definition of "cascaded value"
08:14:01 [fantasai]
which needs to be fixed
08:14:24 [fantasai]
Topic: Conditional Rules
08:14:43 [fantasai]
dbaron: Issue raised by heycam, discussed multiple times over the last month
08:14:48 [stearns]
08:14:49 [fantasai]
dbaron: Fun end-of-token-stream issue
08:15:53 [fantasai]
dbaron: If this is valid, we'd better put the closing tokens in the stream
08:15:58 [fantasai]
SimonSapin: Why wouldn't it be valid?
08:16:24 [fantasai]
TabAtkins: Should error-recovery add the additional necessary tokens
08:16:52 [fantasai]
plinss: I would say that error-recovery creates the necessary constructs, and serialization writes out the appropriate syntax.
08:17:00 [Zakim]
dbaron, you asked to be reminded at this time to go home
08:17:14 [fantasai]
SimonSapin: We don't store tokens, we store component values
08:17:32 [fantasai]
dbaron: supports rule conditions can store things that aren't valid values in CSS
08:17:46 [fantasai]
TabAtkins: Concept of component value he's invoking is from Syntax
08:18:08 [fantasai]
TabAtkins: It augments tokens stream into a nested tree of blocks and tokens and ?
08:18:16 [fantasai]
TabAtkins: We parse that into a parenthese block containing 4 tokens
08:18:30 [fantasai]
dbaron: I'm hesitant to introduce a new concept in how we specify things
08:18:45 [fantasai]
dbaron: because that might imply we need to introduce that concept into the implementation
08:19:06 [fantasai]
dbaron: Chances are you'll write a spec that requires the implementations to add that abstraction layer as a real thing
08:19:53 [fantasai]
TabAtkins: If you encouter EOF, assume the additional necessary tokens to assume those constructs, so that you have a well-formed stream
08:19:57 [fantasai]
glazou: minimal tokens necessary
08:20:08 [fantasai]
SimonSapin: You're not storing tokens, storing constructs
08:20:22 [fantasai]
SimonSapin: When you serialize it will create those constructs
08:20:32 [fantasai]
SimonSapin: Only in variables or invalid @supports conditions will you store tokens
08:21:02 [fantasai]
TabAtkins: So, whether store constructs or tokens treams, identical results
08:21:16 [fantasai]
TabAtkins: So, to answer heycam's question, this would parse correctly, and would imply close parens
08:21:28 [fantasai]
SimonSapin: I think in this case we don't even need to store the parens
08:21:37 [fantasai]
SimonSapin: Just need to store a declaration
08:23:20 [fantasai]
RESOLVED: Whenever error-recovery closes open blocks, urls, strings, functions, brackets, etc., it implies the minimal tokens to close those constructs.
08:23:45 [fantasai]
heycam: Related issue is \ as last character of the stream. It's valid, but need to add another backslash before appending anything
08:24:07 [fantasai]
TabAtkins: The backslash will become a DELIM token containing a backslash, and when you serialize it it will need to be escaped
08:24:15 [fantasai]
dbaron: But when you escape it, it becomes an identifier
08:24:35 [fantasai]
TabAtkins: Ahh..
08:24:51 [fantasai]
The only way to include a literal backslash is to put it as the last character in the stream
08:24:59 [fantasai]
TabAtkins: Could just drop that DELIM token
08:25:11 [fantasai]
glenn: How about ident?
08:25:18 [fantasai]
glenn: In font-family has name idents
08:25:37 [fantasai]
08:26:07 [fantasai]
dbaron: Another proposal, kindof random, backslash at end of stream converts to U+FFFD
08:26:31 [fantasai]
TabAtkins: We do the same thing to nulls
08:26:43 [fantasai]
TabAtkins: That's new behavior
08:27:32 [fantasai]
fantasai: This is a total edge case, it doesn't matter what we do here.
08:28:17 [fantasai]
plinss: Why can't it be a backslash?
08:28:28 [fantasai]
dbaron: Because you can't serialize it into any other context
08:29:50 [fantasai]
plinss: What if you have open string? Couldn't you just close the string?
08:30:24 [fantasai]
plinss: It would normally, at the end of a line, continue the string
08:30:49 [fantasai]
dbaron: Do you want to change the rule (/EOF-> U+FFFDEOF) only for strings?
08:30:50 [fantasai]
plinss: Yeah
08:31:09 [dbaron]
08:31:14 [fantasai]
plinss: A backslash at the end of a line inside of a string, should not turn into anything.
08:31:43 [fantasai]
TabAtkins: I would prefer to handle this case in the escape-handling rules
08:31:56 [fantasai]
TabAtkins: Don't want different behavior
08:32:11 [fantasai]
dbaron: Escape behavior is already contextual wrt strings, because of \EOL
08:32:22 [fantasai]
plinss: Don't see any value to not just ignoring it.
08:32:24 [fantasai]
TabAtkins: OK
08:32:49 [fantasai]
RESOLVED: \EOF turns into U+FFFD except when inside a string, in which case it just gets dropped.
08:33:35 [TabAtkins]
ScribeNick: TabAtkins
08:33:46 [TabAtkins]
heycam: If the final token in the stream is a bad-url or bad-string...
08:33:58 [TabAtkins]
heycam: Those are bad because you've reached the end of the file...
08:34:15 [TabAtkins]
heycam: If you try and fix the lone \ at the end in any way, none of those reserialize to a bad-string or bad-url.
08:35:21 [TabAtkins]
dbaron: I think Tab's revisions to Syntax fix that - you never get a bad-string or bad-url from EOF.
08:35:48 [TabAtkins]
TabAtkins: Yes, that was Zack's (original author of this stuff in 2.1) intention - it's an accident that 2.1 specifies two contradictory recovery behaviors for unclosed strings and urls.
08:36:15 [TabAtkins]
TabAtkins: [explains what results would be produced in various situations]
08:36:25 [fantasai]
ScribeNick: fantasai
08:36:58 [fantasai]
heycam: conditionText attribute is defined to strip string of white space, but that could change the meaning
08:37:14 [fantasai]
heycam: shows example of escaped whitespace
08:37:23 [fantasai]
TabAtkins: need to strip whitespace tokens
08:37:35 [fantasai]
heycam: That's fine
08:38:00 [fantasai]
TabAtkins: That would be an identifier called "a "
08:38:24 [fantasai]
RESOLVED: whitespace tokens are stripped, not necessarily actual white space, from conditionText
08:38:46 [fantasai]
SimonSapin: Do we want to keep the value of badurl or badstring tokens around to serialize them?
08:39:35 [fantasai]
TabAtkins: Syntax right now just puts a token into the token stream, with no other info
08:39:40 [fantasai]
08:39:47 [fantasai]
TabAtkins: Can't ever serialize them
08:39:53 [fantasai]
TabAtkins: Even variables can't sue them
08:40:08 [fantasai]
08:40:36 [fantasai]
SimonSapin: In @supports, we have special error-handlign rule that says something invalid evaluates to false
08:40:40 [fantasai]
SimonSapin: But the rule is stil valid
08:40:52 [fantasai]
SimonSapin: If that invalid thing is a badstring token, how do we serialize it?
08:41:16 [fantasai]
TabAtkins: Media queries, when serialized, serializes as a guaranteed false MQ?
08:41:25 [fantasai]
TabAtkins: Should do same thing with @supports?
08:41:34 [fantasai]
dbaron: I don't think we should do the same with @supports.
08:41:37 [fantasai]
dbaron: Don't think so
08:42:00 [fantasai]
dbaron: The way spec is written now, if you have badstring or baduri, the rule will get stripped
08:42:06 [fantasai]
[because it doesn't match the grammar]
08:42:12 [fantasai]
dbaron: Maybe should call that out explicitly
08:42:19 [dbaron]
s/the rule will get stripped/the @supports rule will get dropped/
08:42:20 [jdaggett]
ah, ok, got it
08:42:55 [fantasai]
SimonSapin: Is allowed syntax for unknown things the same as variables?
08:42:59 [fantasai]
TabAtkins: More or less
08:43:09 [fantasai]
dbaron: We should check that, but not in an F2F
08:43:22 [fantasai]
ACTION dbaron to check that variables and @supports have identical allowances
08:43:22 [trackbot]
Created ACTION-563 - Check that variables and @supports have identical allowances [on David Baron - due 2013-06-12].
08:43:38 [fantasai]
RESOLVED: Clarify that badstring and baduri make @supports rules invalid
08:44:34 [fantasai]
dbaron: Have disagreement between prose and grammar wrt !important, and I think grammar shoudl be fixed
08:44:57 [fantasai]
dbaron: Think !important should be allowed there. Might add other things that could go there, so might as well let it be part of testable things.
08:45:04 [fantasai]
RESOLVED: !important allowed in @supports
08:46:20 [fantasai]
dbaron: Ok, that's all open issues. Will fix in editor's draft
08:46:59 [fantasai]
fantasai: I think the issues that require updates to Conditional Rules are all minor enough to be clarifications. Let's fix them and publish a CR in place
08:47:23 [fantasai]
RESOLVED: Publish CR with updates for CSS3 Conditional Rules
08:48:12 [fantasai]
Topic: Variables
08:48:27 [fantasai]
TabAtkins: Want to exclude badstring and baduri
08:48:32 [fantasai]
dbaron: And mismatched blocks
08:50:51 [fantasai]
TabAtkins: List of tokens you can't put in there: unmatched ) ] }, badstring, badurl, top-level ;
08:51:35 [fantasai]
TabAtkins: Why is ; only disallowed at top-level, but } anywhere?
08:52:32 [fantasai]
plinss: This is error-recovery
08:52:50 [fantasai]
dbaron: Would prefer not to allow unbalanced things
08:53:02 [fantasai]
TabAtkins: Would prefer to disallow ; everywhere then
08:53:11 [fantasai]
SimonSapin, dbaron: don't see why
08:53:51 [fantasai]
dbaron: Consider in the future you want to put a declaration block in there
08:54:02 [fantasai]
08:54:07 [fantasai]
TabAtkins: Ok, fine, I'm cool with this
08:54:23 [fantasai]
RESOLVED: Can't put unmatched ) ] }, badstring, badurl, top-level ; into variables
08:55:34 [fantasai]
08:56:04 [fantasai]
SimonSapin: Publish all the things!
08:56:07 [fantasai]
Meeting closed.
08:56:08 [jdaggett]
08:56:13 [Zakim]
08:56:15 [glazou]
for the day :)
08:56:31 [jerenkrantz]
RRSAgent: make minutes
08:56:31 [RRSAgent]
I have made the request to generate jerenkrantz
09:08:10 [Zakim]
09:08:12 [Zakim]
Team_(css)06:36Z has ended
09:08:12 [Zakim]
Attendees were jdaggett, Meeting_Room
09:22:06 [cabanier]
cabanier has joined #css
09:30:49 [MikeSmith]
have you all been meeting at the Google offices in Roppongi Hills?
09:30:51 [Zakim]
Zakim has left #css
09:30:58 [MikeSmith]
for this CSS f2f, I mean?
09:36:18 [liam]
MikeSmith, I wasn't there today but I believe that's where the css f2f is, yes
09:36:24 [liam]
09:37:36 [MikeSmith]
liam: thanks
09:45:15 [boblet]
boblet has joined #css
09:53:02 [plh]
plh has joined #css
10:06:40 [jdaggett_]
jdaggett_ has joined #css
10:17:40 [glenn]
glenn has joined #css
10:35:45 [Tav]
Tav has joined #css
11:24:01 [shige-o]
shige-o has joined #css
11:36:23 [shige-o]
shige-o has joined #css
11:41:36 [dbaron]
dbaron has joined #css
11:44:01 [zcorpan]
zcorpan has joined #css
11:56:15 [jdovey]
jdovey has joined #css
12:22:10 [liam]
liam has joined #css
12:53:21 [AndChat|474201]
AndChat|474201 has joined #css
12:55:02 [shige-o]
shige-o has joined #css
13:04:09 [sylvaing_away]
sylvaing_away has joined #css
13:04:40 [alexmog_away]
alexmog_away has joined #css
13:05:10 [shans_away]
shans_away has joined #css
13:06:02 [csswg-]
csswg- has joined #css
13:06:39 [leaverou]
leaverou has joined #css
13:26:25 [AndChat|474201]
AndChat|474201 has joined #css
13:29:31 [glenn]
glenn has joined #css
13:42:36 [Cyril]
Cyril has joined #css
13:54:04 [zcorpan]
zcorpan has joined #css
13:57:26 [SimonSapin]
SimonSapin has joined #css
14:03:53 [sgalineau]
sgalineau has joined #css
14:42:46 [zcorpan]
zcorpan has joined #css
14:51:58 [zcorpan]
zcorpan has joined #css
15:01:59 [zcorpan]
zcorpan has joined #css
15:04:00 [zcorpan]
zcorpan has joined #css
15:16:53 [zcorpan]
zcorpan has joined #css
15:36:22 [zcorpan]
zcorpan has joined #css
16:00:27 [MaRakow]
MaRakow has joined #CSS
16:03:39 [arno]
arno has joined #css
16:45:28 [darktears]
darktears has joined #css
16:47:01 [zcorpan]
zcorpan has joined #css
17:35:30 [arno]
arno has joined #css
17:40:49 [glenn]
glenn has joined #css
17:50:02 [sgalineau]
sgalineau has joined #css
18:37:36 [arno1]
arno1 has joined #css
18:49:41 [darktears]
darktears has joined #css
19:03:04 [arno]
arno has joined #css
19:25:40 [nvdbleek]
nvdbleek has joined #css
19:37:25 [zcorpan]
zcorpan has joined #css
19:42:50 [zcorpan]
zcorpan has joined #css
19:52:16 [arronei]
arronei has joined #css
20:02:56 [lmclister]
lmclister has joined #css
20:08:15 [nvdbleek]
nvdbleek has joined #css
20:08:24 [arronei_]
arronei_ has joined #css
20:15:36 [arronei]
arronei has joined #css
20:17:58 [arronei_]
arronei_ has joined #css
20:22:44 [arronei]
arronei has joined #css
20:25:08 [arronei_]
arronei_ has joined #css
20:29:57 [arronei]
arronei has joined #css
20:32:19 [arronei_]
arronei_ has joined #css
20:37:06 [arronei]
arronei has joined #css
20:39:30 [arronei_]
arronei_ has joined #css
20:45:30 [arronei]
arronei has joined #css
20:48:56 [arronei_]
arronei_ has joined #css
20:50:48 [glenn]
glenn has joined #css
20:55:45 [arronei]
arronei has joined #css
20:57:09 [arronei]
arronei has joined #css
21:06:40 [arronei]
arronei has joined #css
21:15:19 [jdaggett]
jdaggett has joined #css
21:37:01 [dbaron]
dbaron has joined #css
22:07:13 [r12a]
r12a has joined #css
22:24:28 [glenn]
glenn has joined #css
22:32:50 [sgalineau]
sgalineau has joined #css
22:47:01 [Tav]
Tav has joined #css
23:12:53 [SimonSapin]
SimonSapin has joined #css
23:24:22 [Tav]
Tav has joined #css
23:51:24 [dbaron]
dbaron has joined #css
23:52:12 [glenn]
glenn has joined #css
23:58:30 [krit]
krit has joined #css