Last Call for CSS Font Loading Module Level 3
Dear fellow chairs, The CSS WG decided to issue a last call for: Title: CSS Font Loading Module Level 3 URL: http://www.w3.org/TR/css-font-loading-3/ Editors' draft: http://dev.w3.org/csswg/css-font-loading/ Abstract: This CSS module describes events and interfaces used for dynamically loading font resources. CSS is a language for describing the rendering of structured documents (such as HTML and XML) on screen, on paper, in speech, etc. The document was published on the 22nd of may during our ftf meeting in Korea, with a deadline for comments of 30 june. Sorry I could not send the announcement before, I was traveling. The changes from last WD are listed at: http://www.w3.org/TR/2014/WD-css-font-loading-3-20140220/#changes We'd like to especially ask the following groups for a review: - WebApps - WebFonts If you plan to send in a review, but need more time, let us know. /Daniel
ITS 2.0, Selectors 4 and Selectors API 2
ITS 2.0 (the Internationalization Tag Set 2.0) [1] is a specification
attaching l10n/i18n properties to elements and attributes of a document
tree through two means:
1. locally, using attributes in the ITS namespace
2. globally, using rules expressed in XML in the ITS namespace and
based on a selecting mechanism (XPath, CSS, ...)
Here are two examples of the above:
locally:
span xmlns:its=http://www.w3.org/2005/11/its;
its:translate=noNASA/span
globally:
rules xmlns=http://www.w3.org/2005/11/its;
version=2.0
queryLanguage=css
translateRule selector=//html:acronym
translate=xpath
xmlns:html=http://www.w3.org/1999/xhtml/
/rules
In the global case, the selecting language of the rule can be chosen
through the @queryLanguage attribute on the rules element. CSS
Selectors are explicitely listed [2] as a valid selecting mechanism and
it would be really nice to see CSS used there. Unfortunately, Selectors
[3] and its Selectors API [4] companion have two problems that are more
or less blockers for Selectors inside ITS 2.0:
a. it's not possible, even in Selectors API 2 [5], to resolve arbitrary
namespaces in querySelectorAll()
b. Selectors cannot target attributes
In the case of querySelectorAll(), we clearly need to extend Selectors
API to allow namespaces. We had little use cases in the past but that's
not true any more. And it's totally false to say we need this for html
only. A spec like ITS 2.0 will be in most cases not implemented natively
but above abstractions like document.evaluate() or querySelectorAll().
We clearly need namespace resolvers like [6] in Selectors API.
In the case of attributes not reachable through Selectors, we may have
almost everything we need in Selectors level 4 to provide a user like
ITS 2.0 with a solution: the subject indicator [7] could be easily
extended the following way:
1. only one subject indicator is allowed per compound selector
2. the subject indicator can precede a universal selector (potentially
omitted), a type element selector or an attribute selector. In the
case of an attribute selector, the selector represents then the
attribute node matching the condition expressed by the attribute
selector. Note: all @foo attributes of the document is not ![foo]
- that means !*[foo] - but *![foo]
3. both Selectors and Selectors API should allow such attribute
matching, but CSS rules with such attribute matching would of
course not trigger any style resolution. querySelectorAll() and
friends should be extended to return attribute nodes. The case
of a group of selectors where one of the selectors uses a subject
indicator to match attributes has to be discussed but I think it's
doable.
The above would allow to express any ITS rule not only using Selectors
but also in the future in a CSS-alike syntax. Then instead of:
rules xmlns=http://www.w3.org/2005/11/its;
version=2.0
queryLanguage=css
translateRule selector=html|acronym![title]
translate=css
xmlns:html=http://www.w3.org/1999/xhtml/
/rules
we could have the readability of:
@namespace html url(http://www.w3.org/1999/xhtml;);
html|acronym![title] { its-translate: no; }
and have it merged with CSS, use the power of the cascade, etc instead
of having to rely on... ahem... XPath. We could solve two problems of
ours at the same time: *finally* extend Selectors to attribute nodes
and fix that painful hole of Selectors API not working with namespaces.
[1] http://www.w3.org/TR/its20/
[2] http://www.w3.org/TR/its20/#css-selectors
[3] http://www.w3.org/TR/2011/REC-css3-selectors-20110929/
[4] http://www.w3.org/TR/2013/REC-selectors-api-20130221/
[5] http://www.w3.org/TR/selectors-api2/
[6] http://is.gd/HVrWM5
[7] http://dev.w3.org/csswg/selectors4/#subject
/Daniel
Re: ITS 2.0, Selectors 4 and Selectors API 2
On 02/07/13 02:53, Daniel Glazman wrote: rules xmlns=http://www.w3.org/2005/11/its; version=2.0 queryLanguage=css translateRule selector=//html:acronym translate=xpath xmlns:html=http://www.w3.org/1999/xhtml/ /rules Sorry, the above is obviously wrong, please read rules xmlns=http://www.w3.org/2005/11/its; version=2.0 queryLanguage=xpath translateRule selector=//html:acronym translate=no xmlns:html=http://www.w3.org/1999/xhtml/ /rules instead. Thanks. /Daniel
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
Le 21/06/12 13:18, Arthur Barstow a écrit : Daniel, Fantasai - please confirm whether or not Anne's latest changes ([1],[2]) address the #2 issue ([3]) that is blocking FPWD: https://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#::backdrop-pseudo-element Fine by me. Thanks. /Daniel
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
Le 19/06/12 09:41, Anne van Kesteren a écrit : On Tue, Jun 19, 2012 at 1:45 AM, fantasaifantasai.li...@inkedblade.net wrote: It looks like you missed #2. I think ::backdrop is clear enough. Not entirely sure what you would expect seeing there more than what it already says. Well, the spec says how it's named, where it is created and still lacks a description of *WHAT IT IS*, functionnally speaking... It would help really a lot to have such an explanation. /Daniel
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
Le 18/06/12 13:09, Arthur Barstow a écrit : On 5/30/12 10:38 AM, ext Daniel Glazman wrote: Le 30/05/12 14:43, Arthur Barstow a écrit : Chris, Daniel, Peter - when will the CSS WG make a decision on the FPWD? We'll try to make one today during our weekly conf-call. Please note that we're going to review the bits of this document falling under CSS WG's wings. In particular section 6. Peter and I already have discovered a few things : 1. position: center in section 6.1 refers to an Editor's Draft that is not actively discussed at this time. Only normative references should be made to CSS specs or the Fullscreen draft will have to wait until that ED becomes a REC to itself become a REC. 2. the ::backdrop pseudo-element is not explained in the document outside of section 6.2. It's unclear to me why it is needed, what it represents, etc. 3. the parenthesis in section 6.2 seems to me to contain a copy/paste error above the element below the element 4. layer and layer 10 in section 6.1 are unclear. Layer is used nowhere in CSS references used in this spec. This must be clarified. Does the latest ED http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html address the above concerns? No, item 2 above is still not addressed, and I guess most readers of the document won't understand what functionally represents ::backdrop. 1. the definition of requestFullScreen() says what are the steps it should run but it does not even say what feature it provides. I think a sentence saying The requestFullScreen() method sends a request for the Element to go fullscreen. Please see section 7 for the Security Considerations attached to this method. is needed. 2. allowfullscreen and iframe in section 7 should be hyperlinks. I note the reference is at WHATWG while it should be at W3C. These two points are still unaddressed too. /Daniel
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
Le 19/06/12 14:10, Arthur Barstow a écrit : Given this interpretation - and of course, please correct it if it is wrong - it appears the only remaining FPWD Showstopper is #2 in the first set of comments. Is that correct? Yes. /Daniel
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
Le 19/06/12 22:48, fantasai a écrit : You could just work in the explanation I sent in http://www.w3.org/mid/4fc64100.3060...@inkedblade.net e.g. | Each element in the top layer's stack has a ::backdrop pseudo-element, | which can be styled to create a backdrop that hides the underlying | document when the element is displayed fullscreen. I think that would address Daniel's comment. Yes. But please note I insist on this only because I think the current prose is absolutely not self-explanatory enough. The CSSWG generally tries to explain the intention of a feature at a high level rather than simply giving the processing model and asking implementers to blindly implement it. This helps spec reviewers understand the goal of the feature and therefore comment intelligently on how it fulfills that goal, and it helps implementers and authors create a mental context for interpreting the rest of the spec text and applying it to real code. Again, yes. I am in particular thinking of implementors who will read this document w/o having followed the discussions here. I know our (W3C) specs are not meant for end-user consumption but it's not a reason to make them hard to understand even to implementors. That's also the reason why I asked to explain requestFullscreen(). It can sound obvious, but it's not. And in fact, we should _never_ introduce a new syntax, API, whatever w/o saying _what it does_ from a functional point of view before explaining how it works. /Daniel
Re: Moving XBL et al. forward
Le 10/03/11 16:26, Dimitri Glazkov a écrit : Ok, this is interesting. Which proposal by Google is ghost of Daniel referring to? I don't think there is one yet? This kind of things for instance? http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Reacting_to_bound_element_state_change /Daniel
Re: Moving XBL et al. forward
Le 10/03/11 16:46, Cameron McCormack a écrit : We should think of XBL as being a DOM-based thing, rather than an XML- based thing. Then we can have HTML syntax for the cases where everything is within a text/html document, and XML syntax for the cases like the ones I brought up, where you might be purely within an SVG document. I disagree. If you do that, the HTML serialization of a binding won't be usable in a user agent having no knowledge of HTML. /Daniel
Re: Moving XBL et al. forward
Le 10/03/11 16:55, Tab Atkins Jr. a écrit : The HTML serialization of an ordinary web page isn't usable in a user agent having no knowledge of HTML, either. Why is this different? Do you have different serializations for another helper technology called CSS ? No. Why should it be different here? /Daniel
CSS WG comments on View Modes Media Feature spec
Hi WebApps Working Group. The CSS WG discussed the pre-LCWD version of your View Modes Media Feature spec [1] during our weekly conf call yesterday. The raw minutes of the call are available [2]. In summary: 1. globally positive feedback about the spec; we agree the feature is needed. 2. this should not be restricted to widgets; we suggest to expand the scope of the document. 3. about values: - is the 'all' value really useful since a (view-mode: all) query is always true? - a rendering can be 'application' and 'fullscreen'; isn't there an orthogonality issue here? Same thing for 'application' and 'maximized' for instance - chrome can be added by the windows manager or by the application itself, does it make a difference? - is a 'hidden' value needed to query whether a window is visible? - if the current medium (CSS-speaking) is 'projection', does it assume view-mode is fullscreen? What about the other way round? (Opera for instance assumes 'projection' when fullscreen is on) - Is it possible to be floating but also have a media type 'projection'? - the background of the viewport is often applied through CSS, and that could lead to circular dependencies because the media query would depend on the result of the cascade - more generally, we think some of the value definitions could be clearer, it can be hard to understand if a given rendering matches a value or not. 4. all these queries could/should have an event-based counterpart so the changes are detectable by code. We understand this is outside of the scope of this spec but that's still an important comment. [1] http://dev.w3.org/2006/waf/widgets-vmmf/Overview.html [2] http://www.w3.org/2010/03/10-CSS-irc Best, /Daniel -- W3C CSS WG, Co-chair
Re: Seeking pre-LCWD comments for View Modes Media Feature; deadline March 17
Here are my personal comments on the document: 1. Overall, it's a good a light document. I agree the feature is needed. 2. I don't understand why this is restricted to Widgets... A HTML page can be dropped on a desktop or be rendered chromeless by Mozilla Prism. A web page can be rendered in a browser in fullscreen mode, etc. All values still make sense in the case of a browser. I think this spec should be made app-agnostic and Widgets should not be the only target. 3. why maxiMIZED and only mini? 4. I think a hidden value makes sense for future system use of webapps... Don't say no immediately and think more about it please. /Daniel
Fwd: Re: Seeking pre-LCWD comments for View Modes Media Feature; deadline March 17
forward from www-style; sorry I forgot public-webapps@w3.org in my message. /Daniel Message original Sujet: Re: Seeking pre-LCWD comments for View Modes Media Feature; deadline March 17 Date de renvoi : Tue, 09 Mar 2010 19:47:12 + De (renvoi) : www-st...@w3.org Date : Tue, 09 Mar 2010 20:46:37 +0100 De : Daniel Glazman daniel.glaz...@disruptive-innovations.com Pour : Arthur Barstow art.bars...@nokia.com Copie à : www-st...@w3.org, Robin Berjon ro...@berjon.com, Håkon Wium Lie howc...@opera.com Le 04/03/10 16:07, Arthur Barstow a écrit : CSS Community, The WebApps Working Group is seeking comments on a pre-LCWD version of its View Modes Media Feature spec: http://dev.w3.org/2006/waf/widgets-vmmf/Overview.html If you have any comments, please send them to public-webapps@w3.org by March 17. -Regards, Art Barstow The CSS WG will discuss it tomorrow during its weekly conf call. Just one minor thing from me: Media Queries are listed as Daniel Glazman et al Let's give back to Caesar what belongs to Caesar so please make it Håkon Wium Lie et al.. Thanks. /Daniel
[selectors-api] comments on Selectors API Level 2
Hi there. (this message contains personal comments and does not represent an official response from the CSS WG) I have read the recent Selectors API Level 2 draft [1] and have a few important comments to make: 1. I don't like the idea of refNodes. I think having the APIs specified at Element level makes it confusing. I would recommend applying the NodeSelector interface to NodeList instead. If queryScopedSelector() and queryScopedSelectorAll() are applied to an Element or a NodeList, the corresponding element(s) are the refNodes of the query. Same comment for matchesSelector(). 2. I am extremely puzzled by the parsing model of scoped selectors. In particular, I think that the :scope pseudo-class introduces things that go far beyond scoping. Let's consider the selector :scope+p. Clearly, it's _not_ scoped since it queries element that are outside of the subtree the context element is the root of. Furthermore, these elements can be queried without scopes, and I don't see why this is needed at all!!! I would recommend dropping the pseudo-class :scope and make a simpler model where a fictional :scope pseudo-class and a descendant combinator are prepended to all selectors passed as the argument of the corresponding APIs. I don't like the idea that implementors will have to check if the first sequence of simple selectors in a selector contains or does not contain a given pseudo-class to prepend something to the context. This is clearly the kind of things I think we should avoid in Selectors in general. 3. the section about :scope does not include error handling. What happens if multiple :scope are present? 4. what's the specificity of that pseudo? Since it's proposed as a regular and non-fictional pseudo, web authors _can_ use it in regular stylesheets, even if it's meaningless outside of a scoped stylesheet. What's the behaviour in that case? What's the specificity? [1] http://www.w3.org/TR/selectors-api2/ /Daniel -- W3C CSS WG, Co-chair
CSS WG comments on Selectors API
Hi, The CSS WG discussed the recent Selectors API LC during this week's conference call, including a discussion on the removal of namespace matching between previous versions of the doc and this one. We have no official comment to make on this document. /Daniel -- W3C CSS WG, Co-Chair
Re: CSS WG comments on Selectors API
Lachlan Hunt wrote: Daniel Glazman wrote: The CSS WG discussed the recent Selectors API LC during this week's conference call, including a discussion on the removal of namespace matching between previous versions of the doc and this one. Are the minutes from this telcon available? http://lists.w3.org/Archives/Public/www-style/2008Nov/0538.html /Daniel
Re: Element Nodelist - ISSUE-6
Doug Schepers wrote: I will create an Element Nodelist specification right away, and if it is approved to go forward (and I don't see why it wouldn't be, since there is considerable support), I am confident that this would not slow down deployment in desktop browsers, and so authors should be able to use it in the same timeframe as Element Traversal. I hope this resolves your issue satisfactorily. A new spec just for that seems to me a steamroller to kill a fly, but as soon as I have the feature, bah. Go ahead. Thanks. /Daniel
