SV_MEETING_TITLE -- 11 Nov 2013

<dbaron> note that there was a little bit of today's pre-meeting stuff in 10-css-irc

<dbaron> TabAtkins, audio is probably going to be painful, since it's going to be painful just in the room

<TabAtkins> yay

<TabAtkins> Hm, rereading the canvas() discussion, I don't understand what dino means by "security issues" with element().

<kennyluck> TabAtkins, timing attack sort of thing?

<hayato_> test

<TabAtkins> hayato_: pong

<TabAtkins> kennyluck: Right, but I don't understand how that can possibly be an issue. Or rather, how one can possibly skirt it with canvas().

<TabAtkins> Moz doesn't seem to have issues with -moz-element() currently.

<TabAtkins> Now, granted, one possible benefit of an element()-like function that's not actually element() is limiting it to elements that provide an image source, so there's no cycle detection required.

<TabAtkins> kennyluck: What do you mean?

<TabAtkins> Ah. We're much reduced from normal due to the meeting being in China.

<SimonSapin> TabAtkins: "security issue" could include reading values of :visited from script?

<plinss> /invite zakim #css

<TabAtkins> Hm, however, there are some *very* good use-cases for the general element().

<TabAtkins> SimonSapin: How could you do that?

<SimonSapin> TabAtkins: I don’t know, but I recall hearing that yesterday

<fantasai> ScribeNick: fantasai

round of intros

<TabAtkins> SimonSapin: I mean, that's the usual timing attack scenario. But I have no clue why element() allows any timing attacks that aren't already allowed.

<TabAtkins> Can we ask Zakim for a room?

plinss: First topic: display: none on fragmentainers

astearns: Overflow fragments container that says that if fragment box has display noe, it doesn't create a box and gets no content

<renoirb> Hello world from #TPAC

astearns: I think I'm going to add something similar to Regions spec, saying that if a region has display: none, it doesn't get any fragment of the named flow
... Question is, whether it remains a region and is something accessible in the named flows JS API, or if we add something to the spec saying that it does not become a region if it's display: none
... I think latter formulation is a little bit more elegant

<TabAtkins> Hm, I wonder how I ask for a room for more time.

ChrisL: Would that mean if you flipped the value of display it forces reflow?
...

astearns: If you .. in JS, can see those named flows and perhaps do someting with them
... problem: if these regions that are not really regions are in the API, have to figure out what info to return for them
... I don't see much value in including them in the region chain api, so my preference is to not include them

ChrisL: You have a chain of elements, a linked list, seemed if you flip display you need to take it out of the list
... Is there overhead for that?

astearns: Same overhead as switching e.g. 'flow-from' property
... I prpose resolving that regions with display: none do not become regions
... I havea list of other things in the spec that don't beocme regions, would put it there.

<TabAtkins> I support this proposal.

astearns: Might consider putting something in the Fragmentation spec about general interaction with display

fantasai: ok

RESOLUTION: regions with display: none do not join the region chain

RESOLUTION: Add note to Fragmentation that display: none fragmentainers do not participate in fragmentation

Selecting Attributes

Jirka: ITS WG, we have been creating REC which defines set of metadata which acn be used in HTML and XML documents in order to improve automatic l10n and translation processes

<dbaron> Present (at table): Alan Stearns, Larry McLister, Rebecca Hauck, Simon Pieters, Jirka Kosek, Koji Ishii, Kazutaka Yamamoto, Taichi Kawabata, Rossen Anatassov, Israel Hilerio, ??? (W3C), Jet Villegas, Chris Lilley, Lea Verou, Sylvain Galineau, Bert Bos, Dirk Schultze, Dean Jackson, Elika Etemad, Steve Zilles, David Baron, Simon Sapin, Leif Arne Storset, Peter Linss

Jirka: In ITS if you've for example suggest some automatic translaion, you can put attribute saying that <b translate=no>
... which means don't translate this element
... Can also make rules to say which elements should / should not be translated
... Similar to how CSS attaches properties to elements
... In ITS, if you would like such general approach, can use either XPath or Selectors
... Wanted Selectors because average Web developer knows Selectors, but not XPath
... So we added support for language such as Selectors
... But we have problem that HTML has human-language data in attributes instead of elements
... Like title attribute, some ppl using data attributes

<jet> TabAtkins: can you hear anything?

Jirka: Cannot apply rules to such text, because Selectors cannot point at attributes
... So we would like to extend Selectors to allow that
... sent mail to www-style about this
... Don't know how to proceed

<SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Nov/0016.html

<Jirka> http://lists.w3.org/Archives/Public/www-style/2013Nov/0016.html

SimonSapin: we could add pseudo-elements that match attributes
... Some issues with this
... First, styling attributes makes no sense in CSS, so new feature would have to be invalid in CSS
... Also Selectors API only returns elements, so could not use feature there either

<TabAtkins> It doesn't have to be invalid in CSS, just never generate a box.

SimonSapin: Intent is to implement ITS with JS using SelectorAPI
... So even if we add this to CSS, JS API would have to be extended to return attributes

<TabAtkins> But the SelectorsAPI part is harder, since we want .find/.qSA to return an Elements (array subclass that contains elements).

Jirka: Selectors abstract says it's generic language for selecting nodes
... So selecting attributes/nodes/comments is within that scope
... Know of some XML editors that extend Selectors in such ways
... There are other publication use cases that need that information
... So maybe need to decide whether Selectors can only apply to elements, or if need some extension

<kennyluck> using @ both for attribute and @-rule seems highly confusing...

Jirka: ... whether extending/modifying JS apis can be done

<TabAtkins> Problem is the fundamental data model. All common uses of Selectors only return elements, and it's hard/odd to make the APIs built up around this handle anything else.

Jirka: ... splitting Selectors from CSS was a good idea ...

<SimonSapin> kennyluck: could be ::attr(foo)

<TabAtkins> And attributes being nodes was always one of the weirder parts of old DOM, imo.

SimonSapin: In my opinion so far, Selectors is really about selecting elements
... And the one mechanism for going around this is pseudo-elements

<TabAtkins> Oooh, suggestion! We could return PseudoElement!

SimonSapin: The issue that needs to be solved for ITS is to find a way for JS API to handle more than elements

<TabAtkins> There's a reason we defined that interface!

ChrisL: We decided to call it Selectors, not CSS Selectors
... Decided that so that it could be useful for other things
... So, SimonSapin is correct -- CSS styles elements, so far only can select elements

<TabAtkins> I think it would be okay for .find() to return an array of Elements and PseudoElements.

ChrisL: If interested in using Selectors for other things, need to extend it for thos ethings
... We're moving from XPath to Selectors W3C-wide, so can't say we don't want to handle someone else's use cases while saying that it's for everyone not for CSS alone

zcorpan: I agree with you that Selectors shoudl be generic, and could make sense to extend it
... But also agree with Simon that I would like to see a proposal for what the SelectorsAPI should look like with this extension in place

<TabAtkins> Hey, yo, check the IRC.

zcorpan: Before extending Selectors with it

Jirka: I was just saying that for ? API, extending selecting is still perf problem or incompatible, can always introduce new types than just Elements

fantasai: So Tab has a comment in IRC

<astearns> fantasai reads Tab's comments above

<kennyluck> I don't think attributes are PseudoElements. What style do they have? (ie. remember that getComputedStyle can inspect pseudo-elments)

zcorpan: If we can return Elements and PseudoElements, then might as well return Elements and PseudoElements and Attr as well

<TabAtkins> kennyluck: A PseudoElement doesn't *need* to be able to generate a box.

<renoirb> <newbie>If i'm not mistaken, Attr is not a property of an Element?</newbie>

<TabAtkins> zcorpan: We're trying to kill the Attr interface. ^_^

<ChrisL> fantasai: send in a concrete proposal

<zcorpan> TabAtkins: no? we're trying to make it not inherit from Node, the object can't be removed

<TabAtkins> zcorpan: Ah.

fantasai: Sounds like the next action is for someone to figure out how Selectors API shoudl be extended, and then come back with that solution and ask Selectors syntax to be extended
...

<kennyluck> TabAtkins, just what exactly should getComputedStyle(el, "::attr") return? An error or an style that has all initial values?

dbaron: I'm not convinced of use case

<TabAtkins> zcorpan: Just sticking with PseudoElement is probably good anyway - we likely want to allow people to, for example, select regions.

dbaron: There was some concerns wrt ... about excess complexity

<TabAtkins> kennyluck: Same as a ::before without a 'content'.

dbaron: Not clear to me feature that was done this way had to be done this way

Jirka: ITS v1.0 wasxpath only, v2.0 adds selectors but they can't get at attributes
... In situations with attributes, not possible to use Selectors

<astearns> TabAtkins: I agree we need to have PseudoElement - I don't know that this is an argument to conflate PseudoElement with Attr

Jirka: I consider Selector sjust another language on top of doucment, like XPath
... My POV is to just extend Selectors. If some other API doesn't support attributes, then doesn't use it

dbaron: Languages aren't designed to do everything.

<TabAtkins> astearns: Yeah, sure, it's not necessarily an argument for, but I already prefer the pseudo-element syntax for grabbing attrs, and it keeps down the set of things we'd return from .find.

dbaron: You're taking a language designed around XPath and trying to swap in Selectors

<astearns> TabAtkins: sure - having a similar interface to get to them makes sense

dbaron: not convinced we should extend Web platform for this spec that you wrote

<ChrisL> really, ITS is the only thing that needs access to attributes?

Jirka: If Selectors is positioning itself as universal selection language, then ..

dbaron: DOM is moving towards model that attrs are not first-classs members of tree like elements are
... Attributes are an API on Elements, they're not a member of this tree
... Model that attributes are like nodes is too complex

zcorpan: Because of existing content, we can't get rid of Attr. Could maybe make it not inherit from Node, but still needs to exist

dbaron: Yes, there's existing things, but movement to change that

Jirka: I think that there is no reason to not support some part of the document because ...
... Attribute is simply [part of the document, doesn't matter how it is represented, it is still storing data belonging to the document. Shoudl be possible to select it

<TabAtkins> I would like to take the few small steps necessary to kill most remaining uses of XPath.

<hober> we shouldn't be adding new api that treats attributes as being node-like

Jirka: I could go to users and say if you want to select attributes, must use XPath

fantasai reads Tab's comment

<TabAtkins> Right, hober, but having something that says "There's data in this attr over here" doesn't seem unreasonable.

<Jirka> TabAtkind: With XPath 2.0/3.0 it would be much more challenging :-)

<ChrisL> tab, yes but we can't say on the one hand stop xpath and on the other hand, we only care about selectors that are good for CSS

<TabAtkins> Jirka: Sure, but I'm not as concerned about that, as there's no browser impls. ^_^

<TabAtkins> ChrisL: Note that I'm not saying that.

<ChrisL> ok good

fantasai: We already have a case where Selectors can select some things in one language (pseudo-elements are OK to select in CSS) but not in another (SelectorsAPI can only return actual elements)
... I don't think it's a stretch to have another language that can do things with Selectors that are invalid in other cases like SelectorsAPI/CSS

<TabAtkins> I care about Selectors that are useful for the web. If there are reasonable APIs on the web that would like to refer to attributes, then having a way to select those seems reasonable.

<ChrisL> this whole issue bout 'is an attr a node' seems orthogonal to whether selectors can get at them

plinss: If we added something to Selectors that allowed selecting attributes, but it didn't work in the API, would that be workable for you?

<TabAtkins> Selectors is *the* tree-traversal/search API on the web.

<dbaron> I guess I just don't understand why we give ITS this level of access to make demands of the CSS WG when we don't give lots of people developing things on the Web that level of access to the CSS WG.

<TabAtkins> plinss: I don't think that's acceptable for the Jirka things.

<TabAtkins> dbaron: We're giving them no more access than anyone else making a request.

Jirka: For us it will be sufficient just extending Selectors, not also changing SelectorsAPI at the same time
... Because in the meantime, there are ways to implement this

<dbaron> TabAtkins, I don't think we give most people making requests big slots on the agenda at a face-to-face.

Jirka: If there are other use cases for SelectorsAPI, can be changed in teh future

<TabAtkins> dbaron: Sure, I've got no comment on that, other than that we're taking time to discuss it, and the relevant person happens to be around.

plinss: Does this work for people? Or ppl opposed to this?

zcorpan: My previous comment still applies, but I would be ok with adding it to Selectors now if it turns out that in a year or something, hasn't been added to Selectors API, then maybe should reverse it

ChrisL: It occurs to me that CSS might also have need for styling attributes, sometimes text would be in attributes, want to style it

fantasai: You're not styling the attribute, you're styling a pseudo-element that has slurped up the attribute's text via 'content'

<TabAtkins> ChrisL: Perhaps. Today that's done as ::before { content: attr(foo); }.

Bert: If you can use Regions flow to pull in attr to content, don't need the pseudo-element

<Bert> we could select an attribute and flow it into a region... '::attr(title) {flow: a}'

<TabAtkins> Bert: That's jumping a bit ahead. You still need to describe how it generates a box, ordering, etc.

<TabAtkins> At that point you're just defining an ordinary pseudo-element.

<TabAtkins> If you can 'flow', you can 'display' without flowing.

plinss: CSS doesn't need it, at least not now, but is this something we should add to Selectors to support the ITS use case?
... Not hearing any clear answers here

ChrisL: Sounds like we've stopped objecting, so need a concrete document for this

fantasai: If we think it's a pseudo-element, would go in a separate document from Selectors

<dbaron__> TabAtkins, jet is holding the microphone up to his laptop's speaker

TabAtkins: I agree with what Chris says
... I don't have any comments beyond what I typed into IRC

fantasai: Jirka did send a proposal, so question is do we want that proposal? Are there other options to discuss?

<Bert> (I think, until somebody founds an objection, '::' seems the best syntax so far.)

<jet> TabAtkins: lots of noise from your line. quiet now though.

fantasai: I didn't read the thread, be good to hear a summary from someone who did

SimonSapin: The initial proposal was with an @sign like in XPath, like @foo for foo attribute
... That's a bit foreign in Selectors, several ppl didn't like it, may be ambiguous with @rules in CSS syntax
... Next proposal was to use pseudo-element syntax
... Which make sense because this would have similar restrictions to pseudo-elements
... e.g. don't have child elements, have to be at the end of the selector

fantasai: Also it's only valid in certain contexts, just like most pseudo-elements are only valid in CSS rather than SelectorsAPI

<SimonSapin> pseudo-element syntax proposal: ::attr(foo)

<SimonSapin> or ::attr(ns|foo)

ChrisL: I like what Simon just typed

Bert: go for it

kennyluck: I don't think attributes are pseudo-elements, because they never have styles

<TabAtkins> Note that this selects the attribute off of the selected nodes, regardless of whether there's such an attribute (probably unlike XPath).

kennyluck: they don't generate a box

<TabAtkins> The translation of "@foo" is "[foo]::attr(foo)"

kennyluck: Tab pointed out ::before { content: normal; } doesn't have styles but I think we have ::before because it "sometimes" have styles
... I think we should have other syntax

<TabAtkins> kennyluck: They *might* have styles, if we define how they generate a box.

<SimonSapin> sgalineau, none. This doesn’t do anything in CSS

<kennyluck> @attributes(selector, attrib)

<TabAtkins> kennyluck: But that's pushed down.

<sgalineau> ok, so purely for API selection

<TabAtkins> Oh, no, let's not abuse at-rules to hide selectors in.

fantasai: ....

SteveZ: Another way of saying is that it's not really pseudo-elements, but pseudo-things... broadening the class

(fantasai was explaining that Selector in CSS select things that can have style properties, be they real elements or special pseudo-elements

<TabAtkins> Pseudo-elements are already a weird stretched concept, which are best understood as a combinator that jumps into some other tree.

but SelectorsAPI only selects actual elements,boxes are out-of scope

<TabAtkins> This explains ::region, ::content, etc.

<TabAtkins> In this case it'd be jumping into the attribute tree.

It would make sense for another language to have pseudo-elements that can select things relevant ot their context, but no pseudo-elements that represent boxes)

dbaron: If this goe sinto the Selectors spec, need to make it *very clear* that this can't be used in CSS to style attributes

<TabAtkins> dbaron: I'm fine with that, and can make it clear.

<dbaron> ...but that it's for selector APIs only

SimonSapin: Pseudo-elements have already moved out of Selectors module

fantasai: Yeah, it would be a separate spec

<SteveZ> Fantasai: we are moving pseudoelements out of the Selectors Spec

Jirka: I'm willing ot be editor of this sepc

<SteveZ> ... because Selectors is already too large and pseudo-elements only apply to CSS anyways

<TabAtkins> Daniel and Alan are already the editors of the relevant spec. ^_^

plinss: Does anyone want to co-edit?

<dbaron> It seems a little odd for it to be a separate spec just for the attribute things

This isn't a CSS feature, there fore it shouldn't go with the other CSS -only features

<dbaron> fantasai: This isn't a CSS feature, therefore it shouldn't go with the other CSS specs. So it's clear this doesn't apply to CSS at all.

astearns: multiple before/after pseudos should be replaced anyway, didn't pass muster

plinss: So, draw up a draft, and we'll review it later
... Anything else on this?

RESOLUTION: Add ::attr() pseudo-element into a new module for non-CSS pseudo-elements

krit asks about discussing WebVTT pseudos

plinss: we'll discuss ::cue after indieui
... Please be back promptly at 11, we have a joint meeting

<jet> TabAtkins: let's work on the phone thing during break

<jcraig> TabAtkins, why is ::nth-fragment in a different spec from css-pseudo?

<TabAtkins> jcraig: Not any particular reason, except that the spec for it is kinda complicated.

<richardschwerdtfeger> would someone put the passcode in the channel please?

<TabAtkins> richardschwerdtfeger: Calling in isn't working right.

<richardschwerdtfeger> ok. thanks Tab

<jcraig> Is the phone problem room-specific? We were on the PF call a few minutes ago.

<TabAtkins> jcraig: Seemingly, yeah.

<jcraig> It'll be difficult to present the topic if I can't call in. Ted O'Connor may be able to speak to some of it.

<TabAtkins> At least, we tried to have Zakim call Wuzhou_East, and it repeatedly didn't work.

<jcraig> but he's in WebApps now

<richardschwerdtfeger> can someone run a Skype call and have us connect in?

<TabAtkins> Apparently we have a bad polycom unit.

<TabAtkins> Skype might work for others, yeah. We haven't tried it yet, because I can't skype from my computer.

<richardschwerdtfeger> or could borrow the polygon from the PF room

<richardschwerdtfeger> polycon

<richardschwerdtfeger> :-)

<Bert> Tab, still there? We have an engineer lookng at the Polycom.

<plinss> Tab, the polycom may be sorted, try calling zakim again

<richardschwerdtfeger> what is the passcode?

<richardschwerdtfeger> went quiet

<dino> can you hear anything?

<richardschwerdtfeger> line now dead

<jcraig> zalkim, drop Wuzhou_East

<dino> the meeting hasn't actually started, but you might hear background noise

<TabAtkins> dino: No, the problem is that calling Wuzhou_East is failing.

<TabAtkins> Zakim isn't able to connect to it.

<dino> we heard you for a moment though

<TabAtkins> That's... strange.

<richardschwerdtfeger> I can hear James

<dino> that was wwaaaaaay too quit

<dino> quick

<TabAtkins> richardschwerdtfeger: Yeah, us in the call can hear us.

<TabAtkins> dino: That's what I keep telling you. ^_^

<TabAtkins> We can hear a ringing sound, then dead line.

<dino> can you hear bert?

<TabAtkins> Nope.

<jcraig> Should I attempt explanation via IRC?

<dino> we heard a ringing sound this time

<richardschwerdtfeger> line died again

<TabAtkins> Can y'all hear the dead line beeping?

<jcraig> Yes, I hear the busy signal.

<MichaelC> zakim call wuzhou_east

<dino> that was easy

<TabAtkins> Woo, works!

<dino> jcraig: we'll have microphones soon

<TabAtkins> D'oh, wuzhou dropped.

<TabAtkins> Hm...

<TabAtkins> This totally worked a second ago.

<TabAtkins> jcraig: Nope, I'm at home in Cali.

<dino> we need Michael Cooper to do whatever magic he did last time

<dino> we did

<dino> (of course we have no idea what the hotel telephone system is doing behind the scenes)

<TabAtkins> Looks like we can kind of hear the room now.

<TabAtkins> At least, sometimes. It's spotty, but it's working.

<dino> looks?

<TabAtkins> Like, it's fading in and out at about 1hz

<scribe> ScribeNick: fantasai

<dino> can people on the phone hear peter speaking?

<TabAtkins> yes

plinss: IndieUI joining us for presentation

<TabAtkins> dammit

Janina: Thanks for allowing us time
... We have been working on 2 modules, want to talk about today the User Context model, which will allow applications to convey key things based on user prefs

<TabAtkins> Since this phone isn't working, jcraig is wanting to reschedule in the PF room, as they know their phone works

Janina: Recently Apple came up with suggestion that we really liked to use Media Queries

<TabAtkins> Because we've dropped entirely.

Janina: We like it for many reasons

<dino> :(

Janina: And James Craig ahs been redrafting our document, and will provide examples

<TabAtkins> Okay, we're in.

Janina: Once phone starts working, will ask James to present on how we propose to use MQ

<TabAtkins> Nope, out.

Janina: want your reactions to this
... We're fine if we maintain the spec or if migrate to another spec

discussion of phone problems

<richardschwerdtfeger> ok. moving to the PF room

hober: I can pretend to be James for a minute

<jcraig> Clarifying, this was a joint WG agreement to switch to media queries. Ted and I (Apple) came up with a restrictions/privacy/anti-fingerprinting proposed extension to MediaQueryList and @media.

hober: One concrete example from user Context spec tha tmake smore sense as MQ is display-colors-inverted
... To handle case where for a11y reasons,have system-wide color inversion

<jcraig> https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#colors-inverted

hober: Most of the time should be invisible to page

<TabAtkins> I talked to our own a11y people about display-colors-inverted, and support it.

hober: breaks down for content images, some background images
... so that people look in normal colors, not like aliens
... double-inverted MQ allows author to double-invert images so they come out right

<TabAtkins> I thought we could just auto-invert pictures/videos, but apparently a bunch of "little" images, like icons and such, should stay inverted like the text they're next to.

<TabAtkins> Only significant/"content" images and videos need to be re-inverted back to normal.

<dbaron___> Though ted's use case sort of depends on knowing the exact inversion in order to re-invert

<dino> fantasai: I would prefer we could tag images as not to be inverted, and the UA should handle it

Ted: Using CSS filters to undo inversion seems natural
... Authors in the best position to know whether image should be re-inverted
... MQ just has two keywords, inverted andnone
... But if you wanted to cover different forms of inverted, would need more keywords
... MQ sould then only match systems that have form of inversion

plinss: That seems fragile for me, if different types of inversions

<jcraig> Before we get into specific discussion of individual MQ features, I would like to summarize the approach if rescheduling to a working phone bridge is not an option.

<dino> it's not clear to me that system-inversion is the same as CSS filter invert()

<TabAtkins> I like fantasai's suggestion of tagging elements as not invertible.

<jcraig> Let's don't get hung up on inversion algorithms yet

<jcraig> First of all, from the intro: "The specification below adds several new "Media Features" to detect user settings, using existing syntax defined in the CSS3 Media Queries specification, and provides an access control extension to the MediaQueryList interface defined in the CSSOM View Model."

<jcraig> "Because this approach relies so heavily on features that overlap with work maintained by the CSS Working Group and Web Applications Working Group, it is likely that portions or all of this specification may move under the purview these other groups. At a minimum, the IndieUI Working Group requests guidance and a collaborative working relationship with CSS and WebApps."

<dbaron___> for alternative color inversion, see http://dbaron.org/mozilla/invert-colors#http://www.w3.org/ in Firefox

<jcraig> https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#intro

fantasai: While I support MQ for a11y prefs in general, I don't think this particular case is best handled by MQ. I would rather enable tagging images that shouldn't be inverted and let the UA handle that as appropriate.

hober: Would you allow tagging bg images?

fantasai: Think it should be general to all images
... yes

[dbaron reads jcraig's comments]

<jcraig> The general idea is that sometimes user-specific settings are needed by web apps. Large document suites like Google Docs and iWork for iCloud are examples of this, where they can improve the experience for all users if the app is provided with specific user settings, allowed by the users

<jcraig> but there are real privacy and fingerprinting implications to this

krit: One point, double-inversion can be done with filter function, but agree with fantasai that shouldn't do the double-inversion for the browser, but have the browser do it

hober: ...

krit: Shouldn't be content images in style

<jcraig> for example, not all web pages should know if a screenreader is running, just like not all pages should need to know your location

fantasai: It's not so much content vs not content in this cas,e but mayb ephotographic vs not photographic, etc.

<jcraig> so the general concept is that there are media feature groups that can be restricted (some specific to accessibility, some noty)

janina: bar chart might want inverted, but not ...

<jcraig> https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#example-restricted-call-to-matchmedia

fantasai: Also might want to invert luminosity but not hue in the bar chart, if talking about colors in the paragraph text nearby

<richardschwerdtfeger> is the phone working now?

janina: Ability to control that definitely a plus

<dbaron> though inverting luminosity but not hue is actually kind of hard -- if you want to preserve hue you need to either sacrifice accurate luminosity or accurate saturation

fantasai: We have a need to tag images for bidi already, so whatever syntax we use for that can be use dwith this (with additional appropriate keywords)

jcraig: Want to discuss general idea of ? MQ

<dsinger> This general idea was first floated around 2007 (oof), on the WhatWG list and socialized some time around then with CSS <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-June/011709.html>

<ChrisL> in fact, dbaron inverting lightness is relatively easy

<jcraig> if someone in the room could read my IRC comments out loud?

<TabAtkins> Skype into the meeting?

<jcraig> In this example: https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#example-restricted-call-to-matchmedia

<dino> [we are trying to skype in]

<jcraig> if a site author requests access to a "restricted" media feature, matchMedia and @media alway return the default value immediately (don't expose user prefs or privacy)

<dino> fantasai reads james's comments from irc

<TabAtkins> I'm supportive fo the general approach, but unsure about the precise mechanics. Several of these appear to be best done as special values, etc.

<jcraig> but then the user is prompted, and the web app can get an asynchronous callbnack when the setting becomes allowed via addListener or a subsequent call to matchMedia

<dino> can someone on the phone speak out loud?

<jcraig> the specifics of the proposal are rough, but we think the general idea of the privacy modeal is sound.

<TabAtkins> Privacy model seems interesting. So, how do you get permission to access this stuff? On first use, pop a request bar? Explicit JS request? Only explicit user action?

<jcraig> TabAtkins, on first request to mql.matches… or first time @media block (and a rule inside it match)

<TabAtkins> Okay.

<dino> we can hear the phone pretty well

<jcraig> Todo from the spec: Explain how the privacy model works: when user prompted, matchMedia returns false immediately, and only provides the updated match ansynchronously through matchMedia().addEventListener or subsequent requests to matchMedia().matches (e.g. on page reload) so there is never any detectable difference between "No" and "You don't need to know." A restricted @media block never prompts unless both the @media block and an included selector matches.

OK, let's go with this system here. I'll type, you guys talk

jcraig: Before specifics of individual media features, general idea is web app [echo]
... Specific media feature, idea is that
... categories of features that user may not want everybody to know about

<TabAtkins> The @media "only request if there's an matched element" isn't a significant restriction. @media (foo) { * {} } is easy.

jcraig: such as things such as disabilities
... or specific media features
... but also some that are less strict
... which can be currently determined by creatively using CSS and JS
... but thought to make those as media feature as wel
... if you have an @media block with a particular rule, e.g. @media (subtitle)
... would match whether have specific setting on
... if got @media block and rule inside of that
... if the page matched that user setting, and had matching selector, then you would get a user prompt at that time
... web page would return default value until user accepted to reveal actual prefs
... user could set prefs for specific rules
... e.g. any feature related to audio/video, or related to screenreader, or related to color settings
... these could potentially expose user to fingerprinting / privacy concerns

<TabAtkins> I could see the prompt saying "This page wants access to your accessibility preferences. Allow/Deny?".

<TabAtkins> "wants to know about your"

jcraig: would like CSS and WebApps to allow these queries, but in ways that don't expose undue privacy leaks

<dsinger> being asked on every page that contains media that can adapt would (I hope, since all media pages should be accessible) quickly get annoying.

fantasai: I think this seems reasonable to me, as long as the spec is flexible enough to allow UI innovation

<TabAtkins> The spec needs significant review for idiom use, and several of these MQs should instead be values or otherwise handled within normal CSS (such as the color prefs), but otherwise it seems broadly okay.

<jcraig> Thinks it should be more specific than just general "accessibility" settings. There are categories that a user could choose to expose.

jet: So, authors for many years have sucked at writing accessibility features, and people who need those features pick specific UAs that will give them consistent presentation from site to site

<TabAtkins> dsinger: If you want to allow it for all pages, you should be able to set it to always yes.

jet: Allowing author to implement those seems antagonistic to users who need those features the most

<jcraig> Re: annoyance. If a user did not care whether every site knew they wanted captions, they could allow that feature category to all websites.

<TabAtkins> jcraig: Being specific is fine within the context of a settings page, but not within the context of a permissions grant. You want a minimum of permission requests, worded for maximum clarity.

<dsinger> if the natural result that all users set it to say "yes, always" we're not exactly mitigating fingerprinting risk, alas

jcraig: If someone wanted to share, should do that from browsers
... allow all
... flip side is location sharing, where prompt for location settings is not needed on most sites, but needed for spcific sites like maps

janina: Might want to define it once and use it in various different UAs

?: presumably the proposal would have common formats for storing it and so that UAs can then retrieve that info on behalf of user as required. Would extend work somewhat

?: MQ syntax for expressing user's individual prefs, secondly existing apis for interrogating that info, then potentially a format for storing and enabling UAs to retrieve it

<TabAtkins> That sounds far beyond the concerns of CSS. We should just be worrying about the stuff themselves.

Jason: could be a layer on top of that

<TabAtkins> Hahaha, the actual features.

<richardschwerdtfeger> like grouping?

<TabAtkins> I R GUD AT ENGLISH

fantasai: I agree with Tab, that seems like an OS-level feature
... Not something to standardize here

<jcraig> what seems like an OS feature?

<TabAtkins> jcraig: The specification of prefs in a browser-agnostic way.

<TabAtkins> jcraig: /sharing of prefs across browsers.

fantasai: So what I've heard so far is that jcraig wants to make sure that an MQ approach is in general OK
... And we have some concerns about individual features being better handled in other ways than MQ, but others OK

<jcraig> As an example, -ms-high-contrast proposal is clearly within the scope of CSS MF, but it potentially exposes users to privacy/fingerprinting. So I think the privacy model goes hand-in-hand with the CSS features.

Bert: Approach is good, but haven't looked at individual properties yet

<TabAtkins> Several of these are best as values, perhaps a user-pref(<ident>) function.

<jcraig> Should be part of CSSOM

<TabAtkins> And we can hang an API off of window.CSS for querying them directly (triggering the permissions grant - this needs some more thought).

fantasai: Think we agree with the general approach, but want to review more closely individual features to make sure they are best handled as MQ, or should be handled otherwise

<TabAtkins> user-pref(foreground-color), etc.

Rich: How do people feel about named groups?

<richardschwerdtfeger> that was rich

<richardschwerdtfeger> :-)

Bert: Can you explain what that is?

<jcraig> Example: https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#userMediaSettings

<TabAtkins> I think the named groups are more of a "browser/OS categorization suggestion" thing.

<TabAtkins> Like I said, I think that the permissions prompt should be a one-and-done thing.

?: Media features are grouped, and if any oe of those features are prompted for, user will get one prompt, otherwise different prompt

fantasai: I think how the prompts are categorized should be up to the UA

jcraig: ...

<TabAtkins> While permissions might be perma-granted in a granular fashion in the settings page, a request for currently-ungranted prefs should grant everything.

jcraig: Specifics of proposal are rough, but general model is sound

<TabAtkins> Anything else is user-hostile, though I recognize the potential weaknesses.

??: Whatever is decided should follow European privacy model

rich: link?

<TabAtkins> This kidn of info *should* be specified in the spec, but it's less of a concern for the CSS things themselves, except insofar as we need to make sure there is *a* sane way to request permission for these.

??: European privacy and APEC model works for ... US model ...

<richardschwerdtfeger> rich: do you have a link to these models?

fantasai: Further comments?

<jcraig> I think it can work within the existing API for matchMedia

??: iapp.org

<TabAtkins> I'm willing to do a spot review of the spec and present conclusions to the WG.

<ChrisL> http://en.wikipedia.org/wiki/Directive_on_Privacy_and_Electronic_Communications

<jcraig> We meet with WebApps about the same topic later today.

[discussion of timelines]

fantasai: When would you like to assign action to CSSWG to review your draft?

<jcraig> Tab has agreed to review the draft

<MichaelC> last 3 ?? are Katie Haritos-Shea

janina: Probably before FPWD, maybe Jan/Feb? James?

<jcraig> public-indie-ui

ACTION csswg to review User Context Module

<trackbot> Error finding 'csswg'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.

<jcraig> https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html

<TabAtkins> Action tab and csswg to review User Context Module https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html

<trackbot> Created ACTION-593 - And csswg to review user context module https://dvcs.w3.org/hg/indieui/raw-file/default/src/indie-ui-context.html [on Tab Atkins Jr. - due 2013-11-18].

plinss: Timeframe on feedback?

<jcraig> thanks for your time, everyone.

fantasai: next 2 months, I heard

<richardschwerdtfeger> rich: thank you

janina: Sounds fine. We're loose on timeframe, since working to finish events thing

Case closed.

plinss: That brings us to lunch, then digipub joint meeting

<TabAtkins> 1hr?

<TabAtkins> You forgot the dur='' attribute!

<TabAtkins> THIS BREAK LASTS FOREVER

I think the default value for type=lunch is 1.5hr

but I'm not sure about this specific instance :)

shooting for 1:15

return time

TabAtkins ^

<TabAtkins> Sounds good.

<TabAtkins> Okay, I'm gone for about 40 minutes, just in case anyone reconvenes before then.

<dauwhe> http://w3c.github.io/dpub-pagination/index.html

<scribe> ScribeNick: fantasai

DigiPub Joint Meeting

Markus: This interest Group is charged with producing reqs and use cases for digital publishing industry for the open web platform -- things digital publishing wants to do that web platform can't do yet
... Pagination is really important, obviously
... Point o fthis meeting is to go over our progress, and get feedback on it
... Our question is, how should we structure this, document this, what do you need?
... Here's our draft of pagination, which Dave Cramer has been working on
... Sits in context worth mentioning quickly
... Most of you know aobut JLREQ, which was worked on for 5 years before published
... There are other similar documents within i18n starting up
... This document is going to be LatinReq
... To capture publishing requirements for Western typesetting
... It will be use dto draaw concrete requirements for CSS

http://www.w3.org/TR/pagination/

DaveCramer: ...

dc: Looked at JLREQ, realized modeling it on that was impossible
... This is just beginning of what we hope to achieve
... Want to describe what print publishing has been doing for last 100s of years
... And then see what is useful for digitlal books

<Jirka> URL is http://w3c.github.io/dpub-pagination/

<astearns> http://w3c.github.io/dpub-pagination/index.html

dc: For this document, just started writing some introductory material and then diving in to start describing, even in simplest cases, what rules are publishers working with on books, what kinds of things do we care about
... brings up a lot of the issues we need to deal with
... Simple example here of fake edition of Moby Dick, illustrate widows/orphans
... brings up concept of what exactly is a page in context of open web platform
... concern with position of this particular line in the page, concept of concept of spread
... CSS has a setting for saying how many lines ok to leave at top of page, but in most UAs if you set that, what it does is it moves a line from the previous page
... which horrifies publishing community by having two halves of the spread not aligning

dino: What do they want?

dc: First step is to go back earlier in that particular chapter and make some change that will make the problem go away
... first thing we would try is making the previous spread shorter

dino: What do you do if it's the first page of the chapter?

dc: Chapter usually starts a bit down the page, might shift it up a little

ChrisL: These are all manual interventions. Need rules for formatter

dc: Think this problem is mostly solveable conceptually
... Large aspect of labor going into producing traditional book is solving these kinds of issues

ChrisL: First point, if it's not solveable automatically, then CSS can't do it either
... If it is solveable and CSS can do it, then saves costs b/c can be done automatically

dc: Want to follow good craft of layout
... If we have that automatic solution,apply that to digital books, will be huge increase in quality of things out there

Markus: Also scope of what we're trying to do this is both hard-copy formatting, which is a lto of the work that Dave does, to prepare (using HTML+CSS in this case) paper copies
... But also dynamic pagination in reading systems, which ...
... Huge overlap for publisher
... Cost of doing these recalculations, offline it's okay if it takes a few minutes, but in dynamic ebook environment not so okay

dc: Don't have sense of algorithms for that

dino: Wanted to do a lot of these in iBooks, but hard to do

dc: Yeah, everything preior in the documen tis sort of in scope, so searching lots of possibilities

dino: Even handling widows and orhpans as we do requires backtracking, which we don't like to do
... going back more than one page / column ... :(

SteveZ: Question comes up, is there a level of degradation that people can live with in the e-environment htat wouldn't be acecptable in print environment, but would be good enough
... good enough beats out best

dc grumps about Kindle

dc: I have higher expectations. Don't want to give up without trying
... I want to raise the standards of the digital world to match what's possible in print
... Other issues ...
... Common example in novels ... I'm calling them space breaks

<astearns> http://w3c.github.io/dpub-pagination/index.html#space-breaks-and-ornaments

dc: blanki line or two where the thought changes or scene changes
... at page break, looks like misalignment, so if it falls at page break put in visible element, like asterisks
... so want to know if element is at top or bottom of page, to change its appearance. Whole class of things want to change
... I dream of :top-of-page pseudo-elements, e.g., to address a whole class of issue shere

dino: I'm sure our team would love that as well

dc: As we said, just getting started with this effort
... Filling in some of these sections just to learn how to work with this, what level of deatil isappropriate
... Would love to know what you guys would find helpful
... what can we do for you, to help make this move forward

dino: Priorities would be an important thing
... For you as the industry to say what is hugely important
... especially if you have data to back that up
... adn break it down market by market
... e.g. maybe widows isn't important in Korean

dc: Talking with others about similar issues in traditional Chinese, e.g. don't want just one character in a column
... want a minimal amount of content on a page
... etc.
... Want ot minimize disruptions as reader goes from one page to another
... So expect lots of commonalities among writing systems

Markus: Request was for, prioritization of all these things, and also locale

breakdown

dino: We're often told by Japanese publishers, if you don't suppot this type of annotations or whatever, its' a showstopper
... It would be great to get similar types of priorities
... To give another example, italics or obliques in Japanese vertical text
... Possibly it's very uncommon, don't need to spend so much time on it
... So would be helpful to know how many ppl actually impacted by this

SteveZ: One other thing you hit upon is, some things the known algorithms involve backtracking
... whereas other things, like asterisks, which don't really force backtracking
... so to extent knowing tech used to implement is useful thing to identify as well

astearns: I don't think you need to prioritize everything in the document against each other, but to surface the highest-priority items

fantasai: Wrt how much detail, more detail is always better

dino: examples are great
... e.g. looking at your example, I think we implemented widows incorrectly

dc nots that books with short dialog hard to page, 1-line paras great, 3-line paras really hard

dc: 3/4 of a line stranded on top of page is not so bad as half a hyphenated word
... see that in ebooks often, it's noticeably bad

dino: Would also like to see examples of inline images. Never know what to do there
... Obviously never want to split an image across a page, ppl say that's bad
... But at what point is it better to put onn the page by itself, etc.

dsinger: might shift it down by some lines

fantasai: float: inline; ?

dc: Something that comes up a lot in higher-ed textbooks are elaborate series of rules for placement of images and ancillary text. Howe far ca they move away from their reference? What er best practices for stacking floats?
... Want to document these and similar issues

Markus; ON the topic of issues to cover or not, discussing scope at high level

Markus: Want to ask thisare there thing sthat we should focus on or omit that would help right now
... What topics would you like us to prioritize?

SteveZ: one that's currently under discussion is footnotes and their treatment in various columnization strategies would be useful
... Another I noticed is captions. Number of different strategies for handling captions, esp when not around the image

ChrisL: Another thing would be things which are used in print but are also used not in print, and would therefore benefit everyone, that books do better but everyone would appreciate
... Would help generate interest for implementers not focused on books

dc: I worke don custom publishing system for textbooks where there were a lot of internal cross-references, e.g. "in next chapter we find x", no next chapter, what do you say
... Lots of intersting things to look at there

dino: Interesting to ge feedback on what digital book publishing concepts translate to world without pagination
... What then do you do with footnotes

fantasai: position: sticky!

ChrisL: One characteristic is not just that it's scrollable, but also dynamic. Can just pop-up the reference, right there where you're reading it, rather than at the bottom of the page where you're not
... but then you need to be able to shrae the markup

<hober> fantasai: stickily-positioned elements overlap, so that wouldn't fly for multiple footnotes

dino: Would also help for [...]

<TabAtkins> We need to fix the overlap issue for normal stickypos anyway.

<hober> TabAtkins: it's a feature, not a bug

Bert: Would be helpful also to know fallbacks: if you cannot get the thing X that you really want, then what are alternative solutions that woudl be acceptible?

dc: If I can't get a unicorn, can I get a pony?

<TabAtkins> hober: Not quite. Having stickypos be able to push other stickypos out of the way is what's needed some times, but other times you want to stack them.

Markus: Back to pagination
... Spreads,
... Showing 2 pages at same time
... Very often in textbooks, have boxes that occupy two pages of spread,e.g. an image

<hober> TabAtkins fantasai: i suspect wanting things-with-funky-layout to avoid other things-with-funky-layout is orthogonal to the form of funky layout

markus: are spread behaviors something to go into detail on, or not?

<TabAtkins> Frex, lots of <h1>s on a page with no <section> elements, overlapping *kinda* works, but not really - transparent backgrounds or different heights ruin it. You want them to push each other out of the wya.

<TabAtkins> But you want an <h2> to stack under the <h1>, and be pushed away by the following <h2> or <h1>.

dc: ....
... More print-specific than other things here
... that apply to paginated view in ebook reader
... On the other hand, spreads are kindof like columns, who knows

SteveZ: Still have issue of figures that cross
... Is there much of a difference then?

Liam: If you think of a spread as unit you're look ing at at the same time, and consider brochures,
... then you might have a 6-page spread
... So have to think a little beyond 2-page spreads

dc: See things like that in online learning: having thigns side-by-side proves to be a useful ocncept

r12a: spread .. differences in printing material

dino: Are you asking are footers and headers and gutters improtant in ebooks? Yes.

fantasai: well, gutters wouldn't be, but footers and headers would be

dc: headers/footers help reader identify context within a long work. Transcends type of media used to render the work

dc side discussion of gutters and how to chop things like maps so they look good when rinted and bound

SteveZ: I think you've given us a good beginning, and strongly encourage you to keep going
... Everything so far is valuable

dc: I'm in both WGs, so easy to talk to me. Appreciate comments/criticisms/whatever
... look forwarfd to really interesting arguments on what pages are...

r12a: Any ideas on how XSL technologies map into things needed here/
... Can say anything about what CSS is doing?

Liam: Not so easy to answer...
... going forward, during paris f2f, asked about psosibility of starting a task force to do paged media work
... There was approval for that, but expect in the next couple weeks wrt task force within CSS WG
... to discuss paged media things
... Bigger quesiton wrt XSL:FO, we closed that working group
... Partly because we have many people interested in CSSWG and almost no one joining XSL WG
... ...
... Hopefully we will be pushing forward on areas of CSS that do these things
...

[silence]

dc: So, we're eager to continue on this work and will do what we can to help CSSWG
... Thank you for your time and attention

Bert: Before we close, next step? Can we have more often joint sessions?
... to keep up to date on each others progress

dc: Maybe we can work out some communication method or status update between the groups

Markus: ...
... can dod osmehting like today, but more focused on a particulare issue / area

dc invites ppl to join DigiPub IG

Topic closed.

<TabAtkins> I can partially hear the room, yeah.

Outline properties

krit: Would like to discuss outline property
... Right now spec says that everypainted thing gets filtered/ blended
... Turns out that outline property is also used for focus rings, and that is very important a11y, for this reason, seems not sueful to have the focus ring be filtered etc.
... Should masking/filters/blending not affect the focus ring

dino: what about scrollbars?

krit: Good question, right now even scrollbars are affected

TabAtkins: ... more general issue
... also issue of 3d transforms
... Problem is authors often use as extra border effect

krit: So you're saying that outlines should be part of rendering, not a11y?

dbaron: were you talking about outline with scrollbars, or scrollbars with filters?

krit: latter
... I was just focused on outline, but Dean asked what about things like scrollbars
... So now we can ask, shoudl filters/blending affect outline/scrollbars

<TabAtkins> Right. While impls use 'outline' to do focus ring, *authors* use 'outline' as a second border.

krit: So key question is outline same as focus ring?

<TabAtkins> And so treating 'outline' as a focus/a11y thing ends up breaking author use.

dbaron: 2.1 is interesting in a few ways, one is that it actually gives two different options for where outline property can be drawn in painting order
... I think that was despite all implementations using one of them, though I think because preference was for impls to switch to other one

<TabAtkins> I think we should just make focus outlines separate and not controllable by authors, only by browser/user prefs.

dbaron: I think outline property was intended to do focus rings
... So should do focus rings right, and if happens to work for other things fine
... But we get push back from authors when we do things for making focus rings work right
... If I had done things scratch, I would have made focus ring a pseudo-element with a small set of properties that could apply

krit: Still have question of whether focus ring should be can affected by filters
... Do we want to discuss focus and outline, or masking

<SimonSapin> ScribeNick: SimonSapin

krit: I would like to start with a11y of masking & filters
... who thinks a11y of scrollbars on focus rings are a problem?

plinss: I think filter effects on scroll bars is asking for troubles

dino: Filters can change position of elemets

krit: yes

<TabAtkins> Scrollbars have long been stylable already, which has potentially bad effects on a11y.

dbaron: it is a problem for filters to not affect these things

<TabAtkins> (I'm planning to go ahead and spec that at some point soon.)

<TabAtkins> So I don't see the problem with letting filters affect them too.

_ and it may be a problem for them to affect these things

krit: I don’t see a problem with letting filter effects affect them too
... that doesn’t need to be specified because it’s already the case

<TabAtkins> WebKit/Blink/IE all let you arbitrarily style scrollbars.

krit: scrollbars are different from focus rings
... impl, Firefox and Webkit do in most cases
... there is an exceeption for SVG
... HTML, we do filter and mask focus ring
... Firefox does it for SVG
... Firefox applies focus ring on everything

<krit> http://codepen.io/adobe/pen/wLrxu

krit: IE does filter and clip the focus ring
... interop between IE and Firefox
... do we see a negative effect on a11y? do we care?

plinss: potential negative effect, we may want to control

<TabAtkins> I care, but I don't think that making an exception for 'outline' is the solution. I think we should disconnect focus ring from 'outline' and just deal with it.

plinss: filter different parts/layer of elements, maybe UI widgets is just another layer
... let it apply for now, later have ability to control

krit: resolve on that?

<TabAtkins> That way focus rings can be more accurate/useful when 3d transformed, etc.

<TabAtkins> +1

Bert: don’t have a solution
... concern. 2 kinds of applications. Fancy applications with filters and everything, want control
... other hand, reading a document. Don’t want scrollbars to change
... would interfere with ability to read the document
... control to the user or author?
... switch "I don’t want the author to interfere"

<TabAtkins> If you're reading a document, and the author's screwing with scrollbars, that's a broken document. ^_^

Bert: for myself, go fullscreen for readability. Lost if scrollbars are not there

ChrisL: author precedence vs. user precedence, solved with ua, author and user stylesheets
... you should be able to switch with user stylesheets

<TabAtkins> * { filter: none; }

<TabAtkins> * { filter: none; /* I just want to read a document, dammit. */ }

Bert: not goo enouhg both way. Filter on scrollback ,but still no control on width of the scrollbar. Already not good enough

krit: not just filters, all effects
... fine if we want to fix it in the future to make sites more accessible

<TabAtkins> Authors can ruin your document reading/scrolling experience already, in plenty of ways, if they're hostile or incompetent.

Bert: even in document mode, some filters might be useful, but for content only

<TabAtkins> body { overflow: hidden; }, and do all scrolling in JS.

krit: now, no resolution for this. Do we want in issue in the spec?

<TabAtkins> overflow:hidden;height:100%;

krit: address the issue later?

plinss: we can defer, but let’s solve if we can

krit: we can solve it by saying "it should never affect" or "should affect", Bert wants more control

plinss: we can add controls in the future
... can we live without it for a while?

<TabAtkins> Again, filters are but one way someone can incompetently ruin someone's experience. It's nothing new, nor is it particularly easy to misuse. We're worrying too much about this.

plinss: also concerns, filter on scrollbar may or may not be useful. Do we want to clip? Does it make scrollbars unreachable?

[dbaron reads TabAtkins’s comments]

plinss: can we resolve than filters just affect UI?
... as some point work on controls

<dbaron> +1

fantasai: leave undefined

<dbaron> dbaron: no need

RESOLUTION: Effects affect scrollbars and focus rings. We may work on controls later

VTT ::cue pseudo-element

plinss: as long as they inform us of this is happening, we’re ok with TTML WG working on this

RESOLUTION: CSSWG is fine with TTMLWG working on this, with ongoing feedback

(yes, thanks glazou)

(discussing topics)

<ChrisL> party!!

plinss: sounds like we’re out of agenda for today

<glazou> hen is the DigiPub discussion ? already done ?

<fantasai> dino: http://www.w3.org/TR/css-text-decor-3/#text-decoration-skip-property

fantasai: counter styles?

<dino> glazou, yes. it is done.

<glazou> glargl

fantasai: correcting things in the algorithms

<fantasai> http://lists.w3.org/Archives/Public/www-style/2013Aug/0378.html

fantasai: about Hebrew, to support 1000
... need a group separator feature

<TabAtkins> That's not the open issue.

- DRAFT -

SV_MEETING_TITLE

11 Nov 2013

Attendees

Contents

Selecting Attributes

DigiPub Joint Meeting

Outline properties

VTT ::cue pseudo-element

Summary of Action Items

Scribe.perl diagnostic output