http://www.w3.org/TR/2011/PR-css3-namespace-20110811/
CSS Namespaces Module
This is the syntax for declaring namespaces in CSS to be used with
namespace-specific selectors. We've implemented it for over a
decade; I plan to vote in favor unless I hear arguments otherwise.
http://www.w3.org/TR/2011/PR-widgets-20110811/
Widget Packaging and XML Configuration
http://www.w3.org/TR/2011/PR-widgets-digsig-20110811/
XML Digital Signatures for Widgets
I don't know a whole lot about these two, other than hearing the
sentiment that while we're interested in widget-type technology,
I haven't heard of Mozilla interest in these particular
specifications.
http://www.w3.org/TR/2011/PR-view-mode-20110811/
The 'view-mode' Media Feature
This is also part of the W3C widgets effort (see above), but seems
more generally applicable. I haven't thought about the issues in
it much, though.
-David
--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla Corporation http://www.mozilla.com/ 𝄂
--BDS
FWIW this was pulled out of the widgets project and made generic on purpose, in conjunction with the CSS WG. With fullscreen on the way I'd reckon it could prove useful.
--
Robin Berjon - http://berjon.com/ - @robinberjon
I don't think we have any plans to implement these. If possible, I
think it would be worth stating that. Beyond that I think we should
either vote "no", or abstain from voting on these.
/ Jonas
> On Sep 6, 2011, at 21:20 , L. David Baron wrote:
> > http://www.w3.org/TR/2011/PR-view-mode-20110811/
> > The 'view-mode' Media Feature
> >
> > This is also part of the W3C widgets effort (see above), but seems
> > more generally applicable. I haven't thought about the issues in
> > it much, though.
>
> FWIW this was pulled out of the widgets project and made generic on
> purpose, in conjunction with the CSS WG. With fullscreen on the way I'd
> reckon it could prove useful.
>
Yes, we plan to implement this as part of our fullscreen work.
Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]
This spec reinvents jar/xpi/ODF signing in a way that aligns more with
W3C NIH / strategy tax (i.e. uses more XML).
The XML specs that widget signing relies on are notoriously difficult
to implement correctly* (and implementation discrepancies mean that
signatures don't match).
I wish we don't end up having to implement this spec due to its
needless complexity compared to what we already have in the codebase
for xpi signing. I think it would make sense not to vote in support of
this spec, so I suggest "Abstain" (or "No").
Previous email to the WG:
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0165.html
* See for example:
https://issues.apache.org/jira/browse/SANTUARIO-266
https://issues.apache.org/jira/browse/SANTUARIO-236
https://issues.apache.org/jira/browse/SANTUARIO-200
https://issues.apache.org/jira/browse/SANTUARIO-191
https://issues.apache.org/jira/browse/SANTUARIO-140
https://issues.apache.org/jira/browse/SANTUARIO-108
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
The format is pretty simple, but yes... it uses XML :/
> The XML specs that widget signing relies on are notoriously difficult
> to implement correctly* (and implementation discrepancies mean that
> signatures don't match).
I'm still waiting for implementations to hit these issues. This might
have been something that occurred while XML Dig Sig and
Canonicalization algorithms were stabilizing.
> I wish we don't end up having to implement this spec due to its
> needless complexity compared to what we already have in the codebase
> for xpi signing. I think it would make sense not to vote in support of
> this spec, so I suggest "Abstain" (or "No").
I've mentioned a number of times that the W3C is willing to work on an
alternative. Some companies are using this already, it's not that bad
and its optional to the w3c widgets platform.
> Previous email to the WG:http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0165.html
>
> * See for example:
All of those bugs is marked as fixed as of Java 1.4. Crypto stuff is
inherently hard to get right, but the bugs list you present merely
shows that issues have been overcome (in Java at least).