Julian Reschke wrote:
Could you please provide some more information or give an example about
when this would be the case?
Here's a simple past example, if I understand your question correctly.
One can set an onerror handler on Window that will trigger if an exception is
thrown and not
We'd like to actually ship a Selectors API implementation in the near
future, and since we implement namespaces in CSS we need some resolution
on the NSResolver thing. Is it in? Is it out? Are we replacing it
with a string instead? Can we ship something sane without NSResolver at
all?
Sergey Ilinsky wrote:
1) Clearly defined use cases seem to be missing from the proposal, would
it be possible to bring them all to the table?
It's more a matter of sanity of implementation than anything else, for
what it's worth.
2) The changes contradict with DOM-Level-2 Events where
Lachlan Hunt wrote:
Given that IE, Webkit and Opera seem to be in favour of dropping
NSResolver, if Mozilla will agree, I'm more than happy to do so
OK. We talked it over, and this sounds like the best way going forward
for now.
-Boris
Doug Schepers wrote:
2) If DOMNodeRemoved is fired after the mutation, event won't be
capable of bubbling
I don't believe that is correct. DOM3 Event states:
At the beginning of the dispatch, implementations must first determine
the event object's propagation path.
I think Sergey's point
Lachlan Hunt wrote:
Although it still has the requirement to throw a NAMESPACE_ERR when
namespace prefixes that need to be resolved are encountered
http://dev.w3.org/2006/webapi/selectors-api/
In theory it might be better to throw NOT_SUPPORTED_ERR so going
forward you can distinguish
Laurens Holst wrote:
I see, so the motivation for the change request to DOMNodeRemoved is
that the second change request (throwing events at the end, after all
operations) is be impossible to do if events are not always thrown at
the end. And the motivation for throwing events at the end
Lachlan Hunt wrote:
The way I see it, all current impls should throw something if more
than one arg is passed
Which exception should be thrown? Is this something I should define in
this spec, or is it something for WebIDL or some other spec to deal with?
Honestly, I don't care much on that
Lachlan Hunt wrote:
The developers implementing this in Opera has given me feedback saying
that this shouldn't throw an exception because JS allows additional
arguments to be passed to any method, including other DOM APIs, like
getElementById(), etc. Is there a good reason why this should
Garrett Smith wrote:
I already expressed my opinion, agreeing with Liorean. For domstring
arguments, call the internal ToString on the input would be the
general rule, unless otherwise stated. This would seem to cover the
majority of cases.
window.open is one of the cases when things are not
Garrett Smith wrote:
window.open();
Which should be equivalent to window.open(undefined) (and isn't in some
UAs), right?
What should window.open(null) do?
If the first argument is null or undefined or the empty string, no uri
is loaded and an blank/empty window is displayed.
This is
Garrett Smith wrote:
The addition operator results in concatenation when either operand is
a string. This results in a calls to the internal ToString, which is
what I'm suggesting should be the general rule.
All I'm saying is that this will require annotating a very large number
of API
Garrett Smith wrote:
That can be the default, perhaps. But I suspect usually null should
become
, not null.
Why?
Honestly? Because that's what Firefox does right now, except in certain
That is not true. Firefox has Spidermonkey.
The Spidermonkey part is irrelevant for purposes of this
Garrett Smith wrote:
There is no DOM method calld doStuff. Can you provide a concrete
example? Boris couldn't think of one either.
Uh, what? You never said, I don't understand that this applies to all
DOM methods that take a DOMString, so I'd like to have some specific
examples.
In any
Garrett Smith wrote:
Using ToString, the following result would be obtained:
Yes, I know what you get with ToString.
After the method createElement(null) is called, there will be no need
to tell apart null and null. I see that. Why is that a problem?
There are other methods where you DO
Garrett Smith wrote:
Null is not the empty string.
No one claimed that it was. A number of DOM methods are specified as
treating them equivalently, however.
-Boris
Garrett Smith wrote:
2) It violates the DOM Level 3 Core specification, which says: On setting,
any possible children this node may have are removed and, if it the new
string is not empty or null, replaced by a single Text node containing the
string this attribute is set to. Thus, clearly
Garrett Smith wrote:
Well, I'm not so sure. I corresponded with Jonas who indicated that he
though null should convert to .
Jonas was saying that the default behavior for a DOM method passed a
null DOMString should be the same as the behavior if passed . That's
not the same as saying that
Garrett Smith wrote:
I do not see where the spec describes the particular effect when
setting to nul.
Maciej quoted the exact text. So did I. I suggest selecting that text,
copying it, going to your browser, opening up the find dialog or
equivalent, pasting it, and thus getting to see
Garrett Smith wrote:
I contend that the textContent example is not designed in a useful
manner and that having null - sometimes and null - null others
introduces complexity.
Sure. And we're stuck with this complexity. Now where do we go from here?
-Boris
Garrett Smith wrote:
Given that, I suggest moving forward:
Test, then document those methods as having special behavior. Do
this not by a null-value mapping, but by documenting the method's
algorithm in simple terms. e.g. if X is not a string, throw an error
But giving a (per-method)
Garrett Smith wrote:
If I'm reading the right spec[1], OMG IDL defines the string type
string consisting of all possible 8-bit quantities except null.
DOMString isn't an OMG IDL String. It's defined as [1]:
valuetype DOMString sequenceunsigned short;
And no, I'm not sure you're looking
Garrett Smith wrote:
It is not compatible? Where? How?
Node.textContent.
A spec mentioning null for a method
that accepts a string does not make null a string.
See long post with an analysis of the exact OMG IDL meaning of the
DOMString type (which is NOT quite the same as ECMAScript
Boris Zbarsky wrote:
See long post with an analysis of the exact OMG IDL meaning of the
DOMString type (which is NOT quite the same as ECMAScript string, note).
I should note that there is one thing adding to the confusion. The use
of String in the ECMAScript language bindings for the DOM
Garrett Smith wrote:
Any Java method that takes a String can have null passed to it.
Yes, and this is true for any reference type, not only String.
Yep. Point is, DOMString is defined as a reference type.
Are you concerned with what can be passed to a method, or what is a String?
The
Anne van Kesteren wrote:
On Fri, 05 Sep 2008 09:43:29 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
http://foo.com
and
http://foo.com:80
are the same origin but have different string representations.
Yes, authors would have to use the former. (The former is also what
Origin will tell them
Dominique Hazael-Massieux wrote:
The Mobile Web Best Practices Working Group is interested to know
whether XmlHTTPRequest has any actual or planned support for compression
HTTP has Content-Encoding and Transfer-Encoding, no? No special effort
on the part of XMLHttpRequest is needed to make
Michael(tm) Smith wrote:
It's intended in part to be a way to keep all our law-abiding
citizen readers in the general public informed about what progress
if any the group is making on the spec.
But if the information is months out of date, is it useful? Seems to me
that it would be better
Julian Reschke wrote:
Maybe I'm missing something, but why not leave it alone if the MIME type
isn't text/* (the only ones where charset is really relevant)?
An excellent example right there of why! For example, it's relevant for
some application types: application/xml,
Julian Reschke wrote:
Why would you ever *want* to set charset on application/xml or
application/*+xml?
That's a really good question, but people do...
In any case, my other example (JavaScript) remains.
-Boris
Anne van Kesteren wrote:
Well, correcting charset is fine. The suggestion for not putting it
there at all unless the media type is text or it is already present
makes some sense though.
I might be convinced of that, I suppose... but read on.
In any case, my other example (JavaScript)
Anne van Kesteren wrote:
Well 1) quite a few browsers don't add charset automatically yet like
Firefox
True, but the reason we started adding it is that it was non-obvious
otherwise what charset the string was encoded in (UTF-8? Page
encoding?) and this was causing real problems.
and 2)
Krzysztof MaczyXski wrote:
The CSS WG is currently wondering whether elements should be able to be
descendants of some pseudo-elements (notably :selection, :first-line and
:first-letter). So this note may need correction.
Not relevant here. The CSS WG is wondering whether elements should
Stewart Brodie wrote:
This is considered to be a bug in the DOM Core specs, which will
hopefully be fixed by Web DOM Core, which is a proposal Simon Pieters is
working on.
You will still need a new type, as I don't see how you can possibly change
the existing behaviour so dramatically under
Marcos Caceres wrote:
Do you have any suggestions as to how we might move forward? Or a
different approach to solving the problem?
The problem being that a ZIP file doesn't know anything about the types
of files in it?
What Gecko does right now for jar: URIs is somewhat similar to what it
Sean Hogan wrote:
- All the getElement* selectors are matched by straight-forward ways for
checking if an element-node matches the desired constraint.
e.g. getElementsByTagName and tagName, getElementById and id,
getElementsByClassName and className / classList
Honestly, className is not a
Doug Schepers wrote:
Please add an example such as this one:
html xmlns=http://www.w3.org/1999/xhtml;
body
svg xmlns=http://www.w3.org/2000/svg;
font id=mysvgfont
...
/font
/svg
font face=ArialExample/font
svg:font id=anothersvgfont
Norbert Lindenberg wrote:
I would expect the specification to prescribe
- either that the implementation raises an exception when given a
This is in fact required in the normative definitions of querySelector
and querySelectoAll. This could be mentioned in the informative section
here, I
Giovanni Campagna wrote:
- XMLPath and DOM3 XPath actually are implemented: even FF2 supports
document.evaluate, instead selectors api are included only in the very
latest browser (Opera 10 and FF3.1 AFAIK)
And Safari and IE8. But yes, the point that XPath is already supported
as a
Giovanni Campagna wrote:
- Selectors is designed to be fast to match, while XPath had no
such design criterion; as a result it's very easy to write
pathologically slow XPath queries, even by accident. For
non-pathological cases, Selectors are still faster, whether because
Shropshire, Andrew A wrote:
4)Should a web page designer cancel all navigations away from the
page just to be malicious, the user can still close the page (since
closing the page does not fire the onNavigateToNewPage event).
That loses the user's navigation history in that window, so
Giovanni Campagna wrote:
Probably treating the onbeforeunload as a real cancelable event
But the key is that the page must not be able to prevent navigation away
from itself without explicit OK by the user. In other words, while the
UA needs to be able to cancel the unload, the page has no
Giovanni Campagna wrote:
What if we follow completely Andrew's proposal? That is, we allow
cancellation of beforeunload events, but we add an UI control that may
be used to froze JS (in HTML5 terms), preventing a further beforeunload
to be handled and canceled.
That places UI requirements
Shropshire, Andrew A wrote:
I am working a dialog problem now and I have discovered another problem
with Onbeforeunload:
It is called even for javascript URLs which clearly aren't exiting the
page.
I believe this is only the case in some browsers. For example,
IE/Windows does this, but
Shropshire, Andrew A wrote:
One use case for this is to customize the text in the dialog. For
example, right now the developer is forced to use Are you sure you want
to navigate away from this page? ... Press OK to continue, or Cancel to
stay on the current page.
This doesn't make sense if
Shropshire, Andrew A wrote:
It would appear that there are countless ways to crash the browser
and/or lose navigation history
Depends on the browser. If your browser allows web pages to do this,
either complain to the vendor or vote with your feet and switch to a
better browser. ;)
2.
Shropshire, Andrew A wrote:
For those that don't, making the unload event cancellable won't break
anything (it won't be fired multiple times because the first time it's
fired is the last for the page because it gets unloaded on the first
fire since these existing web apps don't know that it can
Shropshire, Andrew A wrote:
These pages deserve to be broken :)
That's true of most pages on the web if you apply that criterion. In
fact, I have yet to run into any real-life (not example, not testcase)
web page that wouldn't be true of.
Breaking sites like that is a non-starter for
Shropshire, Andrew A wrote:
One could simply deprecate the onunload (but still support it) and
create a new version onDestroy that is called as well. Old apps won’t
know about onDestroy so it will be harmless and won’t break them. New
apps simply don’t need to implement onunload and will
A few comments:
1) In section 7.3, boolean attributes are defined to use
case-insensitive matching. Why is that? There doesn't seem to be a
definition of case-insensitive here, which worries me, since
case-folding is always tricky business (see below). I would suggest
requiring a
Larry Masinter wrote:
Yes, using Zip is a different overall serialization than
MIME multipart, but aren't the problem spaces similar enough
that differences from what is already widespread practice?
MIME multipart would have the side benefit of specifying MIME types. At
the same time,
Larry Masinter wrote:
I'm not sure about 'authoring might be more complicated',
though. The author/sender/creator of a package has a lot more
insight about the types of the components of the package
than the recipient, and if there's any guesswork to be
done, putting the burden on the author
Larry Masinter wrote:
First, it usually isn't authors who personally assign MIME types
to anything.
Indeed. That's one saving grace, since we want more authors creating
web content than there are people who even know what a MIME type is.
MIME types are generally assigned by the HTTP
Marcos Caceres wrote:
Ok, that sounds like a completely reasonable proposal. And you are right, I
had thought about this in totally the wrong way. I did as you suggested:
* widget engines may now support SVG 1.1.
* authors, however, should try to conform to SVG Tiny 1.2.
* conformance
Boris Zbarsky wrote:
Sort of. We use JAR, not ZIP. Any JAR file is a ZIP file, but not vice
versa. In particular, the JAR spec [1] defines that all non-ASCII bytes
are UTF-8.
That [1] is http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html
-Boris
Giovanni Campagna wrote:
2009/1/28 Boris Zbarsky bzbar...@mit.edu:
Giovanni Campagna wrote:
well, assuming that an author will need to match elements across
multiple namespaces, it will be easier to use XPath (that also is
compatible across multiple browsers) than to use horrible workarounds
Marcos Caceres wrote:
Ok, as I know little of SVG, I've asked Doug Scheppers to help me
That sounds like an excellent plan. Thank you!
It is, but this affects more than just Zip. See also [3] with the
problems Limewire had in respect to normalization of Unicode on MacOs
X.
Note that this
Marcos Caceres wrote:
I'm not sure I agree. I think for security reasons, we should tell
implementors how to treat SVG icons (no script, no interactivity). They
won't have to strip down the SVG viewer, just set up constraints (which
they need to do anyway).
Ok, I tend to agree with you that
Jere Kapyaho wrote:
Treating svg icons in widgets in the same mode as img pointing to SVG
sounds great to me.
So in essence you would tell the SVG engine to rasterize the vector image in
whatever size is suitable for the widget engine?
Not necessarily, no. Of course the rasterization
Scott Shattuck wrote:
From the SVG Specification, Section G.7 Conforming SVG Viewers
...
Specific criteria that apply to only /Conforming Dynamic SVG Viewers/:
* *The viewer must have complete support for an ECMAScript binding
of the **SVG Document Object Model*
Jonas Sicking wrote:
So do I, and most likely the rest of mozilla.
Seconded.
-Boris
Cameron McCormack wrote:
If that does end up being the more common behaviour, I’ll change the
default in Web IDL to be to stringify to undefined unless overridden,
For what it's worth, that's what the current WebIDL draft says in any case.
-Boris
John Resig wrote:
As of last night's nightly WebKit has the first 100% passing implementation.
Interesting. Did they do this by violating the If the user agent also
supports some level of CSS, the implementation SHOULD support the same
set of selectors in both these APIs and CSS
Ian Hickson wrote:
http://www.hixie.ch/tests/adhoc/dom/selectors/002.html
Given the state of WebIDL, it's not clear to me that the test 002 of
this test is necessarily required by the spec as it stands. For that
matter, it's not clear to me that test 001 is.
Also, I would like to ask
Ian Hickson wrote:
However, I don't think the things tested in 002 are controversal. In
particular, all the UAs have converged on the behaviour tested by 002-001
for other objects
Ah, that wasn't the case last I checked. And again, there's no
specification I can find that requires it.
Ian Hickson wrote:
For the Selectors API as far as I can tell it's trivial to implement, no?
Just put the APIs on the other interfaces directly.
That fails for non-JS embeddings of Gecko, for various reasons. So no,
pretty nontrivial.
-Boris
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
Anne van Kesteren wrote:
On Mon, 23 Mar 2009 14:49:17 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
Just as a point of record, I believe browser implementors were split
on the issue (e.g. I think in Gecko live performance would be as good,
if not better in many cases, as non-live performance
Anne van Kesteren wrote:
http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0066.html
http://lists.w3.org/Archives/Public/public-webapi/2007Apr/0009.html
I read those. That was long after this was initially discussed though.
And also around the time I stopped being the active editor of
Giovanni Campagna wrote:
So why not adding a parameter on openDatabase() to specify what kind
of database we want (and what kind of query language we will use)?
I mean something like
openDatabase(name, version, type, displayName, estimatedSize)
where type can be any string
so, for example, type
Giovanni Campagna wrote:
We have a standard SQL, and we have DBMS-specific extensions (for
SQLite, for MySQL, for SQLServer, etc.).
The latest version is ISO/IEC 9075:2008 Information technology --
Database languages -- SQL, released in 2008, but actively being
revised, according to the ISO
Maciej Stachowiak wrote:
I agree that no such thing as standard SQL (or rather the fact that
implementations all have extensions and divergences from the spec) is a
problem. But I am not sure inventing a brand new query language and
database model as proposed by Vlad is a good solution to this
Maciej Stachowiak wrote:
I don't think this one point should be decisive by itself. But I don't
think it should be given zero weight either.
Agreed (in case that wasn't clear).
Note that one of the clients in question is the offline-enabled mobile
version of GMail. I think this demonstrates
Nikunj Mehta wrote:
One clear problem identified despite these examples is that we do not
have a precise enough spec for the query language to make truly
independent interoperable implementations possible.
There are several different query languages that can be interoperably
implemented -
Sean Hogan wrote:
sessionStore[2] = howdy;
print(sessionStore[2]); // prints null?
Where, exactly? That gives howdy in Gecko, at least. At least with
s/sessionStore/window.sessionStorage/.
-Boris
Ian Hickson wrote:
Local display of images before uploading them requires being able to take
a File object and poke it into parts of the platform that currently only
take URLs. I suggest that the way we address this is by adding an API to a
File object that returns a URL like this:
Cameron McCormack wrote:
* Renamed DOMString to string:
http://dev.w3.org/2006/webapi/WebIDL/#idl-string
I thought there had been at least some mention of this colliding with
existing string types in IDLs that are already in use? I know this will
make it much harder for Mozilla to use
Giovanni Campagna wrote:
Then we need a discussion about the possibility of having a spec for
XMLSerializer, having already DOM3LS.
Which probably needs changes similar to what Henri proposed to actually
work correctly with HTML5.
-Boris
Lachlan Hunt wrote:
I've also begun to add tests for the namespace selector syntax [2] to
the second set, but they are currently a work in progress and are not
functioning properly. If anyone can figure out what I've done wrong,
please let me know.
I'm glad to try to figure that out, if you
Lachlan Hunt wrote:
Both Minefield and Webkit trunk are failing those tests for me. I have
all but one commented out just so it would make my debugging easier (see
lines 287 to 292 in 002.html).
Oh, I'd just missed the one failing test. Showing only failing tests
helped!
I just checked
Robin Berjon wrote:
Do other implementers care to chime in with what they do, and if they'd
find this change acceptable?
As I recall Gecko's behavior, it works more or less like this:
1) Properties listed as readonly in the DOM 2 Events IDL are in
fact readonly.
2) init*Event may be
Jeremy Orlow wrote:
I don't know what you mean by this. LocalStorage only cares about the
origin.
Ah, indeed. I'd gotten lost in all the spec changes in this area...
For reference, https://bugzilla.mozilla.org/show_bug.cgi?id=495337
-Boris
On 9/24/09 2:17 PM, Garrett Smith wrote:
On Thu, Sep 24, 2009 at 6:06 AM, Boris Zbarskybzbar...@mit.edu wrote:
Gecko doesn't. Webkit doesn't.
I just checked really quickly, and on my machine (a year-plus old laptop)
That is probably many times faster, and can probably be much more
liberal,
On 9/24/09 2:36 PM, Sam Weinig wrote:
WebKit now also has an implementation of Element.matchesSelector() (we
are calling ours webkitMatchesSelector for the time being).
[https://bugs.webkit.org/show_bug.cgi?id=29703]
Right. The Gecko one is mozMatchesSelector.
I bet we'd both love to rename
On 9/24/09 5:09 PM, John Resig wrote:
It's only if it's an array that we have to do the dance. Even in the
case where the array of results is already in document order the sort
will be incredibly fast (O(N)).
O(N) in number of nodes in the array, and that assumes that the array is
not being
On 9/24/09 6:45 PM, Sean Hogan wrote:
That is surprising. Does the CSS engine do the same? If the CSS engine
doesn't store the parsed selector then it probably doesn't matter for JS
calls either.
In Gecko the CSS engine stores the parsed selector. In addition, it
stores the selectors in
On 9/25/09 9:59 AM, Lachlan Hunt wrote:
Yes, the reference elements parameter will accept either a single
element, Array or NodeList.
What about HTMLCollection? Or have we finally made that interface
inherit from NodeList?
Another question I just had reading this, and this is probably a
On 9/25/09 1:35 AM, Garrett Smith wrote:
No, you did not say it is slow. I'm saying that your laptop is
probably a lot more powerful than a mobile device with a browser, such
as Blackberry9000. Do you agree with that?
Sure. It's a pretty self-evidently true claim.
that said, note that on a
On 9/26/09 4:36 PM, Lachlan Hunt wrote:
A scoped selector string is a string that begins with an exclamation
point followed by a the remainder of the selector.
This assumes that '!' will never be allowed at the beginning of a CSS
selector, right? Have you run this by the CSS working group?
On 9/27/09 3:30 AM, Brendan Eich wrote:
I believe we could get rid of custom deleters from the Web platform if
Firefox and IE remove support for custom deleters in LocalStorage,
refuse to add it back, and refuse to implement it for DOMStringMap. If
that happened, I'm sure other browsers and the
On 9/27/09 2:28 AM, Maciej Stachowiak wrote:
This is not an issue for DOM methods. It's an issue for interfaces such
as HTMLCollection and HTMLFormElement that support indexing by function
call syntax, for legacy compatibility reasons.
Huh. Gecko hasn't supported this, and we haven't had
In section 4.4.2 of WebIDL, there is the following language:
As soon as a name N begins being able to be used to index
the host object, a property called the corresponding named
property MUST be created on the host object...
IndexGetter has similar verbiage. I'm really not clear on this
On 10/12/09 5:06 AM, Anne van Kesteren wrote:
FWIW, this is what I've done now. It gives authors a reasonable level of
control over the Content-Type header, it does make sure an incorrect
charset parameter is fixed, and includes a charset parameter and MIME
type if the author did not include a
On 10/12/09 11:58 AM, Anne van Kesteren wrote:
If you do something as simple as
application/xhtml+xml;charset=utf-8
it will be corrected so it should be fine.
Oh, I see. So you made it so charset is never _added_ if the
content-type is set, but will be corrected if present?
However, it
On 10/20/09 11:25 PM, Maciej Stachowiak wrote:
It might be worth adding annotations to the spec to say this API is
terrible, do not use and this API is terrible, do not follow its
design.
Are there any DOM Core methods where those notes would not apply? :-)
Node.parentNode is mostly ok. ;)
On 11/10/09 8:33 PM, Anne van Kesteren wrote:
This should be a bit more exact as to how the mediaType is returned. I
would prefer ASCII-lowercase. Returning application/octet-stream
rather than null also seems better if the type is not known. That way
you do not have to type check. Other parts
On 11/10/09 11:58 AM, Anne van Kesteren wrote:
True, can you ever get this situation when reading a file from disk?
I'm not sure what you're asking... When loading a file from disk, the
type is always unknown and has to be determined by the UA somehow, no?
Sure, but there's also
On 11/25/09 3:46 PM, Klotz, Leigh wrote:
The XMLHttpRequest functionality described in this document has
previously been well isolated, and in fact XHR itself has beeen
implemented by a number of different desktop browser vendors by
copying the original implementations.
Note that these were
On 11/26/09 9:58 AM, Lachlan Hunt wrote:
Actually, correction. Minefield and Opera don't meet the condition if we
keep the shipping requirement in the exit criteria.
Which imo we should. I don't think we want to be opening up that loophole.
The Gecko 1.9.2 branch builds have the
On 11/26/09 11:52 AM, Charles McCathieNevile wrote:
And I don't see any problem with using public development builds.
The main problem I have with them is that they have typically not gone
through the sort of full QA cycle that would point out possible problems
in the implementation of the
1 - 100 of 759 matches
Mail list logo
