RE: [PE] Interop Status Update
-Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Monday, July 01, 2013 7:20 AM On 6/27/13 1:05 AM, ext Jungkee Song wrote: Hi, I updated the Interop status of Progress Events: http://www.w3.org/wiki/Webapps/Interop/ProgressEvents Based on your updated data, it appears we have meet the CR exit criteria since every test now has at least two implementations that pass it. As such, it seems like we can start a CfC to publish a Proposed Recommendation. Chaals, All - do you agree? It may depend on the interpretation of the #1 condition of the CR exit criteria: http://www.w3.org/TR/2011/CR-progress-events-20110922/#crec Regarding the bugs filed with Blink, I've discussed with Kentaro Hara and Christophe Dumez about the possible timeline of the relevant patches. I thought things seemed to be optimistic (https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/47SxtdMBKc s), but the answer was it may be fixed by the end of this year as a few V8 APIs need to be added. With the current interop status and the implementation feedback, I would like to propose a CfC to publish PR at least. WDYT? Jungkee having two identical ongoing issues in Blink. FYI, I have not tested the WebKit nightly build yet. It would be appreciated if someone shares the result. To Microsoft team, Do you have any dev update in IE10 which brings any changes in the test result? It would indeed be good if we had more Passes. Can anyone from Opera indicate if the non-Passes for Presto will be fixed or not (and if so, when a public version will be available)? -ArtB Thanks and regards, Jungkee Jungkee Song Samsung Electronics
Re: Overlap between StreamReader and FileReader
On Mon, Jul 1, 2013 at 9:03 AM, Takeshi Yoshino tyosh...@google.com wrote: Moved to github. https://github.com/tyoshino/stream/blob/master/streams.html http://htmlpreview.github.io/?https://github.com/tyoshino/stream/blob/master/streams.html Why would it be neutered if size is not given? When size is not given, we need to mark it fully read by using something else. I changed to use read position == -1. I'm not sure I follow. Isn't the maxSize argument optional so you can read all the data queued up thus far? It seems that should just work and not prevent more data queued in the future to be read from the stream. (Later on in the algorithm it seems this is acknowledged, but at that point the stream is already neutered.) I think you need to define the stream buffer somewhat more explicitly so that only what you decide to read from the buffer ends up in the ArrayBuffer and newly queued data while that is happening is not. Do you want FIFO model to be empathized? It doesn't emphasis, it just needs to be clear. Probably defining Stream conceptually and defining read() (I don't think we should call it readAsArrayBuffer) in terms of those concepts You mean that something similar to XHR's responseType is preferred? Do we even need that? It seems just passing ArrayBuffer in and out could be sufficient for now? What's pending read resolvers? -- http://annevankesteren.nl/
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: ITS 2.0, Selectors 4 and Selectors API 2
On Mon, Jul 1, 2013 at 5:53 PM, Daniel Glazman daniel.glaz...@disruptive-innovations.com wrote: 1. only one subject indicator is allowed per compound selector That's already the case - the subject indicator has to precede the 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] This is unacceptable for Selectors applied against HTML in general. Attributes are *not* nodes, either in HTML or XML, and ![foo] refers to an element. Against an arbitrary document language where attributes are translated into a tree in a different manner, it would work. 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. I am strongly against Selectors returning different results when used in CSS versus qSA/find. If you want Selectors to be able to select attribute nodes, address it directly with a new selector. This should not be smuggled in via the subject indicator. ~TJ
Re: ITS 2.0, Selectors 4 and Selectors API 2
On Mon, 2013-07-01 at 19:46 -0700, Tab Atkins Jr. wrote: [...] If you want Selectors to be able to select attribute nodes, address it directly with a new selector. This should not be smuggled in via the subject indicator. Maybe it would be simpler to support an XPath() selector? When you start using ITS you'll find other cases that get difficult with existing CSS selectors, e.g. . partShortDescription elements whose id attribute value appears in the list of id attributes in the includes attribute of a partsDiagram element in the same section, and where that diagram has a language=only attribute on the replacementCopies element, and the diagram issue year is earlier than 1996. This sort of thing is fairly frequently written with XPath selectors today, and is a plausible use case (e.g. the older exploded parts diagram is only available in spanish, includes Spanish labels for the parts that readers will have to match up to a table of part numbers, so they need the same text in the diagram and in the table). A rigorous comparison of XPath with CSS selectors would be worth doing; piecemeal attempts to duplicate functionality don't seem worthwhile to me. On the other hand I do agree that it sounds like some limitation in CSS selector namespace handling could be alleviated. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
