Mmmm.
And how we define more than one viewmode?
I mean, apart from the default one for the content, was not decided to give
to the developer the possibility of declaring what modes the widget supports
and how (in terms of size)?
Am I missing something?
Thanks
---
Ivan De Marino
Orange Labs
One (possibly minor) point regarding the filename rule:
At least the Widgets 1.0 PC spec uses ABNF (RFC 5234) and refers to it, maybe
this would be good also in the DigSig spec?
The rule expressed in ABNF would be something like:
signature-filename = signature non-zero-digit *DIGIT .xml
Hi,
The Selectors API test suite is missing tests for the namespace
selectors |foo and *|foo. Since they don't have prefixes that need
to be resolved, they should be supported even without an NSResolver.
See brief IRC discussion about this:
http://krijnhoetmer.nl/irc-logs/whatwg/20090312#l
Alexey Proskuryakov wrote:
12.03.2009, в 17:19, Lachlan Hunt написал(а):
WebKit has a bug with the |foo selector.
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/28
Opera and Firefox pass
This is actually a difference in createElementNS(null, p) vs.
createElementNS(, p)
Alexey Proskuryakov wrote:
This is actually a difference in createElementNS(null, p) vs.
createElementNS(, p) behavior. I don't know whose bug it is, but in
Firefox and Opera, empty and null namespace arguments both result in
null namespace for the created element.
Interesting question. DOM
12.03.2009, в 18:01, Boris Zbarsky написал(а):
Make of this what you will. But as I recall, the change in the XML
Namespaces section was meant precisely to ensure that in JS passing
for all namespace URIs would work exactly like passing null.
Sounds like webkit either implements
Sorry for the delayed reply - I agree with Frederick's comments and
would like to go further and suggest we add a note on how
implementations could be smart. Might be worth doing from a security
point as well as there could be ways of being smart that aren't so smart
if you get what I mean...
Here is a revised proposal to updated Widget Signature to use ABNF. We
have to make adjustments since the strings are case sensitive now.
Here are the change to the editors draft [1] required:
1) Change section 1.1, Notational conventions as follows:
Replace
This specification uses the
Hi Frederick,
One line of the ABNF quoted below could be adjusted to match
RFC5234: 3.4. Value Range Alternatives: %c##-##.
non-zero-digit = %d049-%d057
could be
non-zero-digit = %d049-057
Also I think that decimal encoding could be changed to hex encoding.
Since the strings are already
Hi Frederick, All,
Some comments on the updated specification but first let me again say
thanks for doing a great job making all the changes!
---
Substantive comments
---
3
Implementers are encouraged to provide mechanisms to enable end-users
to
the ABNF spec used decimal for the character encoding examples and hex
for the digit range. I thought I should try to be consistent :).
Thanks for the fix on the range, there also a couple of typos in the
proposal text I can fix.
Shall I keep the characters in decimal and change the
Hi Frederick,
ABNF spec in ABNF (section B.1 of RFC5234) uses only hex base.
HTML5 uses only hex base.
Some other RFCs, e.g. RFC 3261 (SDP), use only hex base.
So I would stick only to hex base.
Of course, the base does not matter that much, it's just formalism.
Thanks.
Kind regards,
Marcin
here is revised proposal, thanks Jere and Marcin
regards, Frederick
---
1) Change section 1.1, Notational conventions as follows:
Replace
This specification uses the following syntax to define filenames.
Characters are appended to numbers to indicate cardinality: ? (0 or
1) * (0 or more) + (1
13 matches
Mail list logo
