date:20101103

On Tue, Nov 2, 2010 at 7:55 AM, David Carlisle d.p.carli...@gmail.com wrote:

 Personally I agree with you that this desire to make html elements forcibly
 close the surrounding math elements is entirely bogus, and it causes all sorts
 of problems in annotation-xml (where you really want nested html) but we 
 failed
 to convince the html WG (or the html editor) of that and so ended up with a
 special case workaround for annotation-xml

 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9887#c16

 sometimes you have to take what you can get:-)

I will take a look.


 However I don't agree that using the token elements as extension points is 
 only
 necessary because of html parser strangeness, I think it leads to a cleaner
 design, and better fallback behaviour for systems that do not understand the
 foreign elements, in any case.


Uncle!  This will take some work to get working correctly with the
implementation in WebKit.  Right now, in XHTML documents with MathML,
we get non-token XHTML for free.  Within MathML token elements, this
won't necessarily be the case.  For example, the 'mo' element renderer
as currently implemented won't preserve child rendering objects.
We'll need to detect these situations and decide what to do.

It would have been nice if MathML 3 had a foreign token element or
indication via attribute typing so that we'd know that there is some
kind of non-MathML content children that should be rendering according
to the host language.  We'll now have to have some kind of de-facto
default set of rules that say that mixed content within a MathML is
identified and handled slightly differently (especially if it contains
things like SVG).

That is, we'll need to detect things like:

mathmo random text svg ... /svg  more random text/mo/math

While this example is rather pathological, it is still possible and
should render as a stack of line boxes wrapped in the inline-block for
the 'mo'.

Also, this:

mathmtext div .../div /mtext/math

should be equivalent to the XHTML chunk:

math xmlns='http://www.w3.org/1998/Math/MathML/'div
xmlns='http://www.w3.org/1999/xhtml'.../div/math

Both of the above examples should work today but once we implement the
renderers for mtext/mi/mn etc. we'll need to take this foreign
element rendering into account.

-- 
--Alex Milowski
The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered.

Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] coding style of #include statements

2010-11-03 Thread Patrick Roland Gansterer

Currently, the style guidelines specify Includes of system headers must
come after includes of other headers. 
But what about WebKit headers in arrow brackets?

What is the correct style:

#include ArgumentEncoder.h
#include WorkItem.h
#include wtf/HashSet.h
#include wtf/OwnPtr.h 
#include QApplication
#include QLocalServer

or 

#include ArgumentEncoder.h
#include WorkItem.h
#include QApplication
#include QLocalServer
#include wtf/HashSet.h
#include wtf/OwnPtr.h 

I prefere the first one because wtf/*.h aren't real system headers.

- Patrick
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] coding style of #include statements

2010-11-03 Thread Osztrogonac Csaba


Hi,

Now the second one is correct, because you should use angle
brackets ... for system headers, and quote marks ... for
non system headers. I think you should use wtf/HashSet.h.

It is important, because searches order is different with ... and ...:
http://gcc.gnu.org/onlinedocs/gcc-4.3.2//cpp/Include-Syntax.html#Include-Syntax

#include file:
1.) -I ... directories
2.) -isystem .. directories
3.) standard system directories

#include file:
1.) in the directory containing the current file
2.) -iquote
2.) -I
3.) -isystem
4.) standard system directories

br,
Ossy

Patrick Roland Gansterer írta:

Currently, the style guidelines specify Includes of system headers must
come after includes of other headers. 
But what about WebKit headers in arrow brackets?

What is the correct style:

#include ArgumentEncoder.h
#include WorkItem.h
#include wtf/HashSet.h
#include wtf/OwnPtr.h 
#include QApplication

#include QLocalServer

or 


#include ArgumentEncoder.h
#include WorkItem.h
#include QApplication
#include QLocalServer
#include wtf/HashSet.h
#include wtf/OwnPtr.h 


I prefere the first one because wtf/*.h aren't real system headers.

- Patrick

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] coding style of #include statements

2010-11-03 Thread Andras Becsi


Hi,

on the contrary, I think ... is correct for WTF headers, because they 
are framework headers, and the include path where the WTF headers are, 
is added with -I, so the preprocessor will find them first. That's why 
almost all WTF includes use #include ... (there are only ~20 occasions 
where  is used for WTF headers, which is wrong in my opinion, but not 
a coding style issue).


The sentence in question should rather say something about -style and 
-style header includes to avoid confusion.


That said, I think the correct order is:

#include ArgumentEncoder.h
#include WorkItem.h
#include QApplication
#include QLocalServer
#include wtf/HashSet.h
#include wtf/OwnPtr.h

because alphabetical order matters here.

BR,
Andras

On 11/03/2010 01:06 PM, Osztrogonac Csaba wrote:

Hi,

Now the second one is correct, because you should use angle
brackets ... for system headers, and quote marks ... for
non system headers. I think you should use wtf/HashSet.h.

It is important, because searches order is different with ... and ...:
http://gcc.gnu.org/onlinedocs/gcc-4.3.2//cpp/Include-Syntax.html#Include-Syntax


#include file:
1.) -I ... directories
2.) -isystem .. directories
3.) standard system directories

#include file:
1.) in the directory containing the current file
2.) -iquote
2.) -I
3.) -isystem
4.) standard system directories

br,
Ossy

Patrick Roland Gansterer írta:

Currently, the style guidelines specify Includes of system headers must
come after includes of other headers. 
But what about WebKit headers in arrow brackets?

What is the correct style:

#include ArgumentEncoder.h
#include WorkItem.h
#include wtf/HashSet.h
#include wtf/OwnPtr.h #include QApplication
#include QLocalServer

or
#include ArgumentEncoder.h
#include WorkItem.h
#include QApplication
#include QLocalServer
#include wtf/HashSet.h
#include wtf/OwnPtr.h
I prefere the first one because wtf/*.h aren't real system headers.

- Patrick

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] HTML5 Parsing amp; MathML

2010-11-03 Thread David Carlisle



Alex,

 Uncle!  This will take some work to get working correctly with the
 implementation in WebKit.


Sorry about that.

   Right now, in XHTML documents with MathML,
 we get non-token XHTML for free.  Within MathML token elements, this
 won't necessarily be the case.  For example, the 'mo' element renderer
 as currently implemented won't preserve child rendering objects.
 We'll need to detect these situations and decide what to do.

Hmm, the mathml3 spec particularly recommends mtext as the extension point
although I think it made sense to specify all the token elements for the parser,
to switch to html rendering as it's much easier for validation or convention to
restrict the document type than to extend the parser later.

 It would have been nice if MathML 3 had a foreign token element or
 indication via attribute typing so that we'd know that there is some
 kind of non-MathML content children that should be rendering according
 to the host language.

But elsewhere you argue that such an element isn't needed and you should just be
able to drop in other namespaced elements anywhere. in fact MathML3-in-(x)html
does specify such an element, namely content of mo mi mtext are specified as
being html.

 We'll now have to have some kind of de-facto
 default set of rules that say that mixed content within a MathML is
 identified and handled slightly differently (especially if it contains
 things like SVG).

differently to what? Sorry I'm not sure I understand what you mean here, can't
you just always view the content of mtext as inline html: it basically has the
same content model as the content of an html span. SVG is allowed there just
because it's allowed in any inline html.  Clearly if you are looking up the
content of mo in an operator dictionary that will only succeed if the mo only
contains character data, but even if the mo does contain character data the
dictionary lookup will fail in general if you have a finite dictionary and an
arbitrary string as the content of the mo, so having it fail on mixed content
isn't (in the abstract) any different, although I accept that an implementation
may have different concerns.

 That is, we'll need to detect things like:

 mathmo random text svg ... /svg  more random text/mo/math

as above i don't see why you need to detect such things any more than you need
to detect


span random text svg ... /svg  more random text/span


In fact your original proposal was that mathspan.svg should just
work, and so what is to stop mtext being treated exactly like span?

David





___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] WebKitGtk app memory leaks , please help

2010-11-03 Thread Fedor Kryukov


After calling webkit_web_view_get_dom_document() and similar functions (
webkit_dom... * ) memory is not freed, what am I doing wrong?

I wrote simple application which handle events (
load-started/load-finished/etc ) and make some changes in loaded page DOM
content, so after loading several pages I have a lot of lost memory, no idea
how to release it.

I tried to use g_object_unref, but it destroys something..
-- 
View this message in context: 
http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30121202.html
Sent from the Webkit mailing list archive at Nabble.com.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebKitGtk app memory leaks , please help

2010-11-03 Thread Holger Freyther

On 11/03/2010 03:52 PM, Fedor Kryukov wrote:
 
 After calling webkit_web_view_get_dom_document() and similar functions (
 webkit_dom... * ) memory is not freed, what am I doing wrong?


Can you provide us with a simple test application, open a bug, attach the test
case to that?

thanks
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] coding style of #include statements

2010-11-03 Thread Darin Adler

The intent is “sorted as the classic Unix command line sort tool would sort 
them”.

-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebKitGtk app memory leaks , please help

2010-11-03 Thread Fedor Kryukov


I'm not sure is this a bug or my fail )
So this is diff to GtkLauncher ( webkitgtk 1.3.5 )
http://old.nabble.com/file/p30123917/main.diff main.diff 

its very simple. So when I use it with page which reloads fast I can see
that it start to eat memory until swap is finished and app fails.

I tried to add g_object_unref( document ); and it helps, but after some
mouse movements over page app crashed and GDB shows this

Program terminated with signal 11, Segmentation fault.
#0  0x00457bb8 in g_type_interfaces () from /usr/lib/libgobject-2.0.so.0
(gdb) bt
#0  0x00457bb8 in g_type_interfaces () from /usr/lib/libgobject-2.0.so.0
#1  0x0044ca07 in ?? () from /usr/lib/libgobject-2.0.so.0
#2  0x004531e8 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0
#3  0x006c55e1 in
WebCore::GObjectEventListener::handleEvent(WebCore::ScriptExecutionContext*,
WebCore::Event*)
() from /usr/lib/libwebkitgtk-1.0.so.0
#4  0x0082ff35 in WebCore::EventTarget::fireEventListeners(WebCore::Event*,
WebCore::EventTargetData*, WTF::VectorWebCore::RegisteredEventListener,
1u) () from /usr/lib/libwebkitgtk-1.0.so.0
#5  0x008305c7 in WebCore::EventTarget::fireEventListeners(WebCore::Event*)
()
   from /usr/lib/libwebkitgtk-1.0.so.0
#6  0x0083e652 in WebCore::Node::handleLocalEvents(WebCore::Event*) () from
/usr/lib/libwebkitgtk-1.0.so.0
#7  0x00840762 in
WebCore::Node::dispatchGenericEvent(WTF::PassRefPtrWebCore::Event) ()
   from /usr/lib/libwebkitgtk-1.0.so.0
#8  0x00840913 in
WebCore::Node::dispatchEvent(WTF::PassRefPtrWebCore::Event) ()
   from /usr/lib/libwebkitgtk-1.0.so.0
#9  0x008428c7 in WebCore::Node::dispatchMouseEvent(WTF::AtomicString
const, int, int, int, int, int, int, bool, bool, bool, bool, bool,
WebCore::Node*, WTF::PassRefPtrWebCore::Event) ()
   from /usr/lib/libwebkitgtk-1.0.so.0
#10 0x00842de0 in
WebCore::Node::dispatchMouseEvent(WebCore::PlatformMouseEvent const,
WTF::AtomicString const, int, WebCore::Node*) () from
/usr/lib/libwebkitgtk-1.0.so.0
#11 0x00abdc4b in
WebCore::EventHandler::updateMouseEventTargetNode(WebCore::Node*,
WebCore::PlatformMouseEvent const, bool) () from
/usr/lib/libwebkitgtk-1.0.so.0
#12 0x00abe123 in
WebCore::EventHandler::dispatchMouseEvent(WTF::AtomicString const,
WebCore::Node*, bool, int, WebCore::PlatformMouseEvent const, bool) () from
/usr/lib/libwebkitgtk-1.0.so.0
#13 0x00abf8ab in
WebCore::EventHandler::handleMouseMoveEvent(WebCore::PlatformMouseEvent
const, WebCore::HitTestResult*) () from /usr/lib/libwebkitgtk-1.0.so.0
#14 0x00abfc73 in
WebCore::EventHandler::mouseMoved(WebCore::PlatformMouseEvent const) ()
   from /usr/lib/libwebkitgtk-1.0.so.0
#15 0x00e1e6d9 in webkit_web_view_motion_event(_GtkWidget*,
_GdkEventMotion*) ()
   from /usr/lib/libwebkitgtk-1.0.so.0
#16 0x084d9424 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#17 0x0043b8b9 in ?? () from /usr/lib/libgobject-2.0.so.0
#18 0x0043d252 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#19 0x004515e6 in ?? () from /usr/lib/libgobject-2.0.so.0
#20 0x00452c33 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#21 0x00453256 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#22 0x08606636 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#23 0x084d1a5d in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0
#24 0x084d2e07 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#25 0x0016639a in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#26 0x03e945e5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#27 0x03e982d8 in ?? () from /lib/libglib-2.0.so.0
#28 0x03e98817 in g_main_loop_run () from /lib/libglib-2.0.so.0
#29 0x084d33c9 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#30 0x080493aa in main ()




Holger Freyther-6 wrote:
 
 On 11/03/2010 03:52 PM, Fedor Kryukov wrote:
 
 After calling webkit_web_view_get_dom_document() and similar functions (
 webkit_dom... * ) memory is not freed, what am I doing wrong?

 
 Can you provide us with a simple test application, open a bug, attach the
 test
 case to that?
 
 thanks
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 

-- 
View this message in context: 
http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30123917.html
Sent from the Webkit mailing list archive at Nabble.com.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] HTML5 Parsing amp; MathML

On Wed, Nov 3, 2010 at 7:49 AM, David Carlisle d.p.carli...@gmail.com wrote:

 It would have been nice if MathML 3 had a foreign token element or
 indication via attribute typing so that we'd know that there is some
 kind of non-MathML content children that should be rendering according
 to the host language.

 But elsewhere you argue that such an element isn't needed and you should just 
 be
 able to drop in other namespaced elements anywhere. in fact MathML3-in-(x)html
 does specify such an element, namely content of mo mi mtext are specified as
 being html.


Sure. ...didn't win that one!  :)

We have these token categories:

   * identifier (mi)
   * number (mn)
   * operator (mo)
   * text (mtext)
   * space (mspace)
   * string (ms)

What if our use of some chunk of HTML doesn't fit in the
categorization of the above?  I would have been nice to have an
ability to annotate foreign markup as some kind of layout element
implemented in, say, HTML, and then potentially use embedded
additional MathML for inner constructs.  That way, things like
accessibility would know that the foreign markup isn't a terminal
structure of the Mathematics and might know (e.g. via ARIA) the role
of the layout.

...so, that's what I meant.   Just an idea ...

 We'll now have to have some kind of de-facto
 default set of rules that say that mixed content within a MathML is
 identified and handled slightly differently (especially if it contains
 things like SVG).

 differently to what? Sorry I'm not sure I understand what you mean here, can't
 you just always view the content of mtext as inline html: it basically has the
 same content model as the content of an html span. SVG is allowed there just
 because it's allowed in any inline html.

Right.  That's not different from what we'd expect.  In section 3.2.1, it says:

Token elements (other than mspace) should be rendered as their
content, if any, (i.e. in the visual case, as a closely-spaced
horizontal row of standard glyphs for the characters or images for the
mglyphs in their content).

Introduce a few SVG and HTML elements and then you have to make the
assumptions about the children that are being rendered according to
the normal rules (plus mglyph) so that this works:

mi xyzzy div  /div /mi

Without any CSS, that 'div' will be a block whose rendering will cause
a new block to be stacked within the inline.  That's a consequence of
my choice of using inline blocks and allowing the rendering of the
'div' to default to the current internal style within WebKit.  I think
that's the right choice but there might be other interpretations.  For
example, one could say that divs inside MathML have a display property
of inline-block by default.

That choice isn't covered by either MathML3 nor HTML5.  I'm not sure
it should be.

 That is, we'll need to detect things like:

 mathmo random text svg ... /svg  more random text/mo/math

 as above i don't see why you need to detect such things any more than you 
 need
 to detect

Well, that's a consequence of building the rendering tree.  Right now
we don't have a special rendering object for token elements other than
for 'mo'.  In the case of operators, this becomes complicated due to
operator stretching.  It may work out to be straightforward but those
feel like famous last words.  That's all I meant.


 In fact your original proposal was that mathspan.svg should just
 work, and so what is to stop mtext being treated exactly like span?


No much and hopefully it stays that way.

At this point I'm not raising any issue except that I know that our
'mo' implementation is currently broken in this regard.

-- 
--Alex Milowski
The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered.

Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] XPath Issues?

As far as I can tell, these are the only filed issues with XPath
implementation within WebKit:

https://bugs.webkit.org/show_bug.cgi?id=26157
https://bugs.webkit.org/show_bug.cgi?id=12504
https://bugs.webkit.org/show_bug.cgi?id=13233
https://bugs.webkit.org/show_bug.cgi?id=12632
https://bugs.webkit.org/show_bug.cgi?id=12496
https://bugs.webkit.org/show_bug.cgi?id=36427

Anything else out there?  Is it complete?  I'm curious about how
robust this implementation is and what enhancements have been filed
for it.

I'm also looking at what it would take to enhance this implementation
to support XPath 2.0 ...

-- 
--Alex Milowski
The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered.

Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebKitGtk app memory leaks , please help

2010-11-03 Thread Xan Lopez

On Wed, Nov 3, 2010 at 7:52 AM, Fedor Kryukov y...@mail.ru wrote:

 After calling webkit_web_view_get_dom_document() and similar functions (
 webkit_dom... * ) memory is not freed, what am I doing wrong?

 I wrote simple application which handle events (
 load-started/load-finished/etc ) and make some changes in loaded page DOM
 content, so after loading several pages I have a lot of lost memory, no idea
 how to release it.

 I tried to use g_object_unref, but it destroys something..
 --
 View this message in context: 
 http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30121202.html
 Sent from the Webkit mailing list archive at Nabble.com.

The memory management of the GObject DOM bindings is still a work in
progress (unfortunately!). We are trying to figure the best to
automatically collect them, but for now you are correct in saying that
they are essentially leaked until the process is over.

See https://bugs.webkit.org/show_bug.cgi?id=40302 for some discussion
on the topic. Our plan is to have this issue resolved before the next
stable release in April.

Xan


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] XPath Issues?

2010-11-03 Thread Alexey Proskuryakov


03.11.2010, в 9:38, Alex Milowski написал(а):

 https://bugs.webkit.org/show_bug.cgi?id=26157

This is a request to implement an optimization, and one that doesn't seem 
particularly likely to provide material benefits. The optimization has an 
observable effect of reusing the same object though.

 https://bugs.webkit.org/show_bug.cgi?id=12504

Namespace nodes are pure evil, we shouldn't do that.

 https://bugs.webkit.org/show_bug.cgi?id=13233

This is a place to track future optimization ideas and performance tests.

 https://bugs.webkit.org/show_bug.cgi?id=12632

This is correct behavior, but Firefox has a bug. We could match Firefox, but 
with no actual sites known to be affected that doesn't seem important.

 https://bugs.webkit.org/show_bug.cgi?id=12496

An optimization opportunity.

 https://bugs.webkit.org/show_bug.cgi?id=36427

Unspecified behavior, different from Firefox.

 Anything else out there?  Is it complete?  I'm curious about how
 robust this implementation is and what enhancements have been filed
 for it.

I think that the only actual bug we have was not on the list, 
https://bugs.webkit.org/show_bug.cgi?id=34231. JS wrappers should be 
preserved for all reachable nodes, which includes nodes in XPath result sets.

 I'm also looking at what it would take to enhance this implementation
 to support XPath 2.0 ...

XPath 2.0 is not fully compatible with 1.0. JavaScript API for XPath doesn't 
provide a way to choose version - at least, it didn't when I last checked. So, 
we can't really support 2.0.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] XPath Issues?

On Wed, Nov 3, 2010 at 9:56 AM, Alexey Proskuryakov a...@webkit.org wrote:

 XPath 2.0 is not fully compatible with 1.0. JavaScript API for XPath doesn't 
 provide a way to choose version - at least, it didn't when I last checked. 
 So, we can't really support 2.0.


I'm not sure that turns out to be a real issue considering this
particular context.  I've been shopping this idea around here at the
W3C TPAC meeting and many of the incompatibilities may not occur
within the context of the browser with a pre-built DOM.  I'll have to
dig further on that.

It is certainly flawed that you can't choose a version.
Unfortunately, there isn't a good way to test for XPath 1.0 but you
can use an XPath 2.0 only expression to test for XPath 2.0 support.
This should be fixed in the API.

Also, we can't expect to stay at XPath 1.0 forever.

At any rate, this would be considered completely experimental.

-- 
--Alex Milowski
The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered.

Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] XPath Issues?

2010-11-03 Thread Alexey Proskuryakov


03.11.2010, в 10:11, Alex Milowski написал(а):

 many of the incompatibilities may not occur
 within the context of the browser with a pre-built DOM.


WebKit currently applies XSLT to document source, not to pre-built DOM. This is 
different from Firefox, but in strict compliance to the spec.

We have separate XPath implementations for XSLT and for DOM bindings though, 
and the latter operates on DOM indeed (which is in accordance with 
http://www.w3.org/TR/2004/NOTE-DOM-Level-3-XPath-20040226/DOM3-XPath.html).

 Also, we can't expect to stay at XPath 1.0 forever.


Actually, I see this situation as similar to XHTML 2.0. XPath is embedded into 
browsers both directly and via XSLT. Any incompatible specification featuring 
the same name is likely to end up as an academic exercise, dead on arrival.

Looking at Mozilla bugs, they seem to have zero interest in XPath 2.0 and XSLT 
2.0:

https://bugzilla.mozilla.org/show_bug.cgi?id=396966
https://bugzilla.mozilla.org/show_bug.cgi?id=370173

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Size Of Ruby Text?

2010-11-03 Thread Eric Mader

Hi,

As part of my work on ruby text enhancements, I'm implementing the option of 
not counting the height of the ruby text in the overall line height. As part of 
this, I wanted to play with changing the size of the ruby text. I'm trying to 
do this by changing the following lines in WebKit/WebCore/css/html.css:

ruby  rt {
display: block;
font-size: 60%; /* make slightly larger than 50% for better readability */
text-align: center;
text-decoration: none;
}

However, when I change the font-size: attribute to, say, 50%, I don't see any 
difference in the size of the ruby text. (I even tried 25% just to be sure). Is 
this value being set somewhere else?

Regards,
Eric Mader

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Any objections to switching to Xcode 3.2.4 or newer?

2010-11-03 Thread Daniel Bates

Please commit the updated Xcode project files.

Dan

On Oct 6, 2010, at 5:00 PM, Darin Adler da...@apple.com wrote:

 Hi folks.
 
 For those working on Mac OS X: Any objection to upgrading to Xcode 3.2.4? 
 It’s now showing up in Apple’s Software Update for all Xcode users, I believe.
 
 I ask because this adds a developmentRegion = English string to the project 
 file but the older versions of Xcode remove that string. If we all agree to 
 use the newer version, then we can let that string get checked in. If some of 
 us are using the older version it will be frustrating because the string will 
 be removed each time someone edits the project file with an older version and 
 checks it in.
 
 If no one objects, we’ll start checking in the project files with 
 developmentRegion in there.
 
  -- Darin
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Size Of Ruby Text?

WebKit enforces a minimum font size of 9px when no explicit font size is 
specified.  This means that the font for rt cannot fall below 9px if it is 
relative to the user agent default.  It may be that we want to consider 
modifying this minimum for ruby text and allow it to go below 9px though.  I'm 
not sure.

If you make a really big Ruby (e.g., ruby style=font-size:96px and then 
modify the font-size percentage on the rt, you should be able to see it take 
effect.

We should probably just study real-world Japanese examples to see how small 
Ruby typically is allowed to get.  If it can go below 9px and still be 
readable, we should perhaps consider allowing that.

In terms of excluding Ruby text from the overall line height, I don't think the 
font-size of the rt is particularly relevant.  You just want to hack the Ruby 
to turn the ruby text into overflow rather than having it be part of the 
overall height of the inline-block.

dave
(hy...@apple.com)

On Nov 3, 2010, at 1:20 PM, Eric Mader wrote:

 Hi,
 
 As part of my work on ruby text enhancements, I'm implementing the option of 
 not counting the height of the ruby text in the overall line height. As part 
 of this, I wanted to play with changing the size of the ruby text. I'm trying 
 to do this by changing the following lines in WebKit/WebCore/css/html.css:
 
 ruby  rt {
 display: block;
 font-size: 60%; /* make slightly larger than 50% for better readability */
 text-align: center;
 text-decoration: none;
 }
 
 However, when I change the font-size: attribute to, say, 50%, I don't see any 
 difference in the size of the ruby text. (I even tried 25% just to be sure). 
 Is this value being set somewhere else?
 
 Regards,
 Eric Mader
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Size Of Ruby Text?

2010-11-03 Thread Eric Mader


On Nov 3, 2010, at 8:56 AM, David Hyatt wrote:

 WebKit enforces a minimum font size of 9px when no explicit font size is 
 specified.  This means that the font for rt cannot fall below 9px if it is 
 relative to the user agent default.  It may be that we want to consider 
 modifying this minimum for ruby text and allow it to go below 9px though.  
 I'm not sure.

Yes, that's probably what I'm seeing. I'm using default font size, which is 
probably 12pt.

 If you make a really big Ruby (e.g., ruby style=font-size:96px and then 
 modify the font-size percentage on the rt, you should be able to see it 
 take effect.
 
 We should probably just study real-world Japanese examples to see how small 
 Ruby typically is allowed to get.  If it can go below 9px and still be 
 readable, we should perhaps consider allowing that.

I'm sure the detailed spec. addresses this issue. I'll review it.

 In terms of excluding Ruby text from the overall line height, I don't think 
 the font-size of the rt is particularly relevant.  You just want to hack 
 the Ruby to turn the ruby text into overflow rather than having it be part of 
 the overall height of the inline-block.

Of course. The website I was using has the line height set too tight for 
correct display this way, and I just wanted to try a smaller size to see if it 
looked better. OTOH, that site loads a style sheet that overrides the ruby text 
font-size to 6pt, so I can't easily override it, and its' probably displaying 
as 9pt anyhow.

 dave
 (hy...@apple.com)

Regards,
Eric

 On Nov 3, 2010, at 1:20 PM, Eric Mader wrote:
 
 Hi,
 
 As part of my work on ruby text enhancements, I'm implementing the option of 
 not counting the height of the ruby text in the overall line height. As part 
 of this, I wanted to play with changing the size of the ruby text. I'm 
 trying to do this by changing the following lines in 
 WebKit/WebCore/css/html.css:
 
 ruby  rt {
 display: block;
 font-size: 60%; /* make slightly larger than 50% for better readability 
 */
 text-align: center;
 text-decoration: none;
 }
 
 However, when I change the font-size: attribute to, say, 50%, I don't see 
 any difference in the size of the ruby text. (I even tried 25% just to be 
 sure). Is this value being set somewhere else?
 
 Regards,
 Eric Mader
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Size Of Ruby Text?

On Nov 3, 2010, at 2:05 PM, Eric Mader wrote:

 
 Of course. The website I was using has the line height set too tight for 
 correct display this way, and I just wanted to try a smaller size to see if 
 it looked better. OTOH, that site loads a style sheet that overrides the ruby 
 text font-size to 6pt, so I can't easily override it, and its' probably 
 displaying as 9pt anyhow.

We honor small explicitly set font sizes.   The 9px minimum is only enforced 
when it's impossible for the site to know what the real font size would have 
been, i.e., if you are relative to the user agent default.

dave


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Size Of Ruby Text?

In printing the standard is 50% of the base text. For larger point sizes like 
headings, the size of ruby is often smaller than 50%.

http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#en-subheading2_3_3

So, how about we default to 50% and see how they come out. Glyphs designed for 
ruby are optimized for those small point sizes. It is possible on some screen 
resolutions we might want to make it a bit bigger but as screen resolution gets 
higher I think it makes more sense to stick to 50% following the standard in 
printing.

- kida

On 2010/11/03, at 12:05, Eric Mader wrote:

 
 On Nov 3, 2010, at 8:56 AM, David Hyatt wrote:
 
 WebKit enforces a minimum font size of 9px when no explicit font size is 
 specified.  This means that the font for rt cannot fall below 9px if it is 
 relative to the user agent default.  It may be that we want to consider 
 modifying this minimum for ruby text and allow it to go below 9px though.  
 I'm not sure.
 
 Yes, that's probably what I'm seeing. I'm using default font size, which is 
 probably 12pt.
 
 If you make a really big Ruby (e.g., ruby style=font-size:96px and then 
 modify the font-size percentage on the rt, you should be able to see it 
 take effect.
 
 We should probably just study real-world Japanese examples to see how small 
 Ruby typically is allowed to get.  If it can go below 9px and still be 
 readable, we should perhaps consider allowing that.
 
 I'm sure the detailed spec. addresses this issue. I'll review it.
 
 In terms of excluding Ruby text from the overall line height, I don't think 
 the font-size of the rt is particularly relevant.  You just want to hack 
 the Ruby to turn the ruby text into overflow rather than having it be part 
 of the overall height of the inline-block.
 
 Of course. The website I was using has the line height set too tight for 
 correct display this way, and I just wanted to try a smaller size to see if 
 it looked better. OTOH, that site loads a style sheet that overrides the ruby 
 text font-size to 6pt, so I can't easily override it, and its' probably 
 displaying as 9pt anyhow.
 
 dave
 (hy...@apple.com)
 
 Regards,
 Eric
 
 On Nov 3, 2010, at 1:20 PM, Eric Mader wrote:
 
 Hi,
 
 As part of my work on ruby text enhancements, I'm implementing the option 
 of not counting the height of the ruby text in the overall line height. As 
 part of this, I wanted to play with changing the size of the ruby text. I'm 
 trying to do this by changing the following lines in 
 WebKit/WebCore/css/html.css:
 
 ruby  rt {
 display: block;
 font-size: 60%; /* make slightly larger than 50% for better readability 
 */
 text-align: center;
 text-decoration: none;
 }
 
 However, when I change the font-size: attribute to, say, 50%, I don't see 
 any difference in the size of the ruby text. (I even tried 25% just to be 
 sure). Is this value being set somewhere else?
 
 Regards,
 Eric Mader
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Coding style change - Indentation of forward declarations in headers

2010-11-03 Thread Darin Adler

On Nov 1, 2010, at 9:40 AM, Brady Eidson wrote:

 Thoughts?

I agree that  we should find a way to express the existing de facto rule 
clearly, rather than changing all the code to match the wording of the rule in 
the guidelines.

I think the rule is something about indenting code inside namespace except when 
it’s the “main namespace” surrounding an entire source file (header or not).

-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Size Of Ruby Text?

That document also states:

When the size of base characters is very small (for e.g. smaller than seven 
points), ruby which is half the size, will be even more small and illegible. In 
such cases where the size of base characters is very small, ruby is not a 
suitable method of annotation. In those cases, consider other annotation 
methods such as adding the reading in parenthesis immediately after the base 
character.

It also sounds like we need to special case Ruby elements and allow their font 
sizes to go down to about 5px instead of 9px.  Anything lower, and you're 
getting to the point where ruby was unsuitable (according to the text above) 
anyway, since the base text was so small.

I filed:

https://bugs.webkit.org/show_bug.cgi?id=48942

dave
(hy...@apple.com)

On Nov 3, 2010, at 2:29 PM, Yasuo Kida wrote:

 In printing the standard is 50% of the base text. For larger point sizes like 
 headings, the size of ruby is often smaller than 50%.
 
 http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#en-subheading2_3_3
 
 So, how about we default to 50% and see how they come out. Glyphs designed 
 for ruby are optimized for those small point sizes. It is possible on some 
 screen resolutions we might want to make it a bit bigger but as screen 
 resolution gets higher I think it makes more sense to stick to 50% following 
 the standard in printing.
 
 - kida
 
 On 2010/11/03, at 12:05, Eric Mader wrote:
 
 
 On Nov 3, 2010, at 8:56 AM, David Hyatt wrote:
 
 WebKit enforces a minimum font size of 9px when no explicit font size is 
 specified.  This means that the font for rt cannot fall below 9px if it 
 is relative to the user agent default.  It may be that we want to consider 
 modifying this minimum for ruby text and allow it to go below 9px though.  
 I'm not sure.
 
 Yes, that's probably what I'm seeing. I'm using default font size, which is 
 probably 12pt.
 
 If you make a really big Ruby (e.g., ruby style=font-size:96px and then 
 modify the font-size percentage on the rt, you should be able to see it 
 take effect.
 
 We should probably just study real-world Japanese examples to see how small 
 Ruby typically is allowed to get.  If it can go below 9px and still be 
 readable, we should perhaps consider allowing that.
 
 I'm sure the detailed spec. addresses this issue. I'll review it.
 
 In terms of excluding Ruby text from the overall line height, I don't think 
 the font-size of the rt is particularly relevant.  You just want to hack 
 the Ruby to turn the ruby text into overflow rather than having it be part 
 of the overall height of the inline-block.
 
 Of course. The website I was using has the line height set too tight for 
 correct display this way, and I just wanted to try a smaller size to see if 
 it looked better. OTOH, that site loads a style sheet that overrides the 
 ruby text font-size to 6pt, so I can't easily override it, and its' probably 
 displaying as 9pt anyhow.
 
 dave
 (hy...@apple.com)
 
 Regards,
 Eric
 
 On Nov 3, 2010, at 1:20 PM, Eric Mader wrote:
 
 Hi,
 
 As part of my work on ruby text enhancements, I'm implementing the option 
 of not counting the height of the ruby text in the overall line height. As 
 part of this, I wanted to play with changing the size of the ruby text. 
 I'm trying to do this by changing the following lines in 
 WebKit/WebCore/css/html.css:
 
 ruby  rt {
 display: block;
 font-size: 60%; /* make slightly larger than 50% for better 
 readability */
 text-align: center;
 text-decoration: none;
 }
 
 However, when I change the font-size: attribute to, say, 50%, I don't see 
 any difference in the size of the ruby text. (I even tried 25% just to be 
 sure). Is this value being set somewhere else?
 
 Regards,
 Eric Mader
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebKitGtk app memory leaks , please help

2010-11-03 Thread Fedor Kryukov

Thanks,

As I understand this is a WebkitGtk bug only?
So I can temporarily switch to QT WebKit to avoid leaks?

Xan Lopez-3 wrote:

On Wed, Nov 3, 2010 at 7:52 AM, Fedor Kryukov y...@mail.ru wrote:

After calling webkit_web_view_get_dom_document() and similar functions (
webkit_dom... * ) memory is not freed, what am I doing wrong?

I wrote simple application which handle events (
load-started/load-finished/etc ) and make some changes in loaded page DOM
content, so after loading several pages I have a lot of lost memory, no
idea
how to release it.

I tried to use g_object_unref, but it destroys something..
--
View this message in context:
http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30121202.html
Sent from the Webkit mailing list archive at Nabble.com.

The memory management of the GObject DOM bindings is still a work in
progress (unfortunately!). We are trying to figure the best to
automatically collect them, but for now you are correct in saying that
they are essentially leaked until the process is over.

See https://bugs.webkit.org/show_bug.cgi?id=40302 for some discussion
on the topic. Our plan is to have this issue resolved before the next
stable release in April.

Xan

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

--
View this message in context:
http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30126515.html
Sent from the Webkit mailing list archive at Nabble.com.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebKitGtk app memory leaks , please help

2010-11-03 Thread Xan Lopez

On Wed, Nov 3, 2010 at 1:20 PM, Fedor Kryukov y...@mail.ru wrote:

Thanks,

As I understand this is a WebkitGtk bug only?
So I can temporarily switch to QT WebKit to avoid leaks?

Possibly, but I don't know, you should ask them.

Also, both bindings are not equally feature-complete (I believe in
general the GTK+ ones have more features), so you'll have to be
careful with that too.

Xan

Xan Lopez-3 wrote:

On Wed, Nov 3, 2010 at 7:52 AM, Fedor Kryukov y...@mail.ru wrote:

After calling webkit_web_view_get_dom_document() and similar functions (
webkit_dom... * ) memory is not freed, what am I doing wrong?

See https://bugs.webkit.org/show_bug.cgi?id=40302 for some discussion
on the topic. Our plan is to have this issue resolved before the next
stable release in April.

Xan

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

--
View this message in context:
http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30126515.html
Sent from the Webkit mailing list archive at Nabble.com.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Size Of Ruby Text?

2010-11-03 Thread Ryosuke Niwa

I think 5px is way too small. Maybe 7 or 8 at least but even those are
really hard to read in high-resolution displays. See
demohttp://plexode.com/eval3/#ht=5px%3A%3Cruby%3E%3Crb%3E今日%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A5px%3B%22%3Eきょう%3C%2Frt%3E%3C%2Fruby%3Eは%3Cruby%3E%3Crb%3E良%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A5px%3B%22%3Eよ%3C%2Frt%3E%3C%2Fruby%3Eい%3Cruby%3E%3Crb%3E天気%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A5px%3B%22%3Eてんき%3C%2Frt%3E%3C%2Fruby%3E%3Cbr%3E%0A6px%3A%3Cruby%3E%3Crb%3E今日%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A6px%3B%22%3Eきょう%3C%2Frt%3E%3C%2Fruby%3Eは%3Cruby%3E%3Crb%3E良%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A6px%3B%22%3Eよ%3C%2Frt%3E%3C%2Fruby%3Eい%3Cruby%3E%3Crb%3E天気%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A6px%3B%22%3Eてんき%3C%2Frt%3E%3C%2Fruby%3E%3Cbr%3E%0A7px%3A%3Cruby%3E%3Crb%3E今日%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A7px%3B%22%3Eきょう%3C%2Frt%3E%3C%2Fruby%3Eは%3Cruby%3E%3Crb%3E良%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A7px%3B%22%3Eよ%3C%2Frt%3E%3C%2Fruby%3Eい%3Cruby%3E%3Crb%3E天気%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A7px%3B%22%3Eてんき%3C%2Frt%3E%3C%2Fruby%3E%3Cbr%3E%0A8px%3A%3Cruby%3E%3Crb%3E今日%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eきょう%3C%2Frt%3E%3C%2Fruby%3Eは%3Cruby%3E%3Crb%3E良%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eよ%3C%2Frt%3E%3C%2Fruby%3Eい%3Cruby%3E%3Crb%3E天気%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A8px%3B%22%3Eてんき%3C%2Frt%3E%3C%2Fruby%3E%3Cbr%3E%3C%2Fdiv%3Eohh=1ohj=1jt=ojh=1ojj=1ms=100oth=0otj=0cex=1
.

- Ryosuke

On Wed, Nov 3, 2010 at 12:47 PM, David Hyatt hy...@apple.com wrote:

That document also states:

When the size of base characters is very small (for e.g. smaller than
seven points), ruby which is half the size, will be even more small and
illegible. In such cases where the size of base characters is very small,
ruby is not a suitable method of annotation. In those cases, consider other
annotation methods such as adding the reading in parenthesis immediately
after the base character.

It also sounds like we need to special case Ruby elements and allow their
font sizes to go down to about 5px instead of 9px. Anything lower, and
you're getting to the point where ruby was unsuitable (according to the text
above) anyway, since the base text was so small.

I filed:

https://bugs.webkit.org/show_bug.cgi?id=48942

dave
(hy...@apple.com)

On Nov 3, 2010, at 2:29 PM, Yasuo Kida wrote:

In printing the standard is 50% of the base text. For larger point sizes
like headings, the size of ruby is often smaller than 50%.

http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#en-subheading2_3_3

So, how about we default to 50% and see how they come out. Glyphs designed
for ruby are optimized for those small point sizes. It is possible on some
screen resolutions we might want to make it a bit bigger but as screen
resolution gets higher I think it makes more sense to stick to 50% following
the standard in printing.

- kida

On 2010/11/03, at 12:05, Eric Mader wrote:

On Nov 3, 2010, at 8:56 AM, David Hyatt wrote:

WebKit enforces a minimum font size of 9px when no explicit font size is
specified. This means that the font for rt cannot fall below 9px if it is
relative to the user agent default. It may be that we want to consider
modifying this minimum for ruby text and allow it to go below 9px though.
I'm not sure.

Yes, that's probably what I'm seeing. I'm using default font size, which is
probably 12pt.

If you make a really big Ruby (e.g., ruby style=font-size:96px and then
modify the font-size percentage on the rt, you should be able to see it
take effect.

We should probably just study real-world Japanese examples to see how small
Ruby typically is allowed to get. If it can go below 9px and still be
readable, we should perhaps consider allowing that.

I'm sure the detailed spec. addresses this issue. I'll review it.

In terms of excluding Ruby text from the overall line height, I don't think
the font-size of the rt is particularly relevant. You just want to hack
the Ruby to turn the ruby text into overflow rather than having it be part
of the overall height of the inline-block.

Of course. The website I was using has the line height set too tight for
correct display this way, and I just wanted to try a smaller size to see if
it looked better. OTOH, that site loads a style sheet that overrides the
ruby text font-size to 6pt, so I can't easily override it, and its' probably
displaying as 9pt anyhow.

dave
(hy...@apple.com)

Regards,
Eric

On Nov 3, 2010, at 1:20 PM, Eric Mader wrote:

Hi,

As part of my work on ruby text enhancements, I'm implementing the option
of not counting the height of the ruby text in the overall line height. As
part of this, I wanted to play with changing the size of the ruby text. I'm
trying to do this by changing the following lines in
WebKit/WebCore/css/html.css:

ruby rt {
display: block;
font-size: 60%; /* make slightly larger than

Re: [webkit-dev] Size Of Ruby Text?

Yeah, that demo makes me think maybe 9px is fine after all. :)

dave

On Nov 3, 2010, at 3:56 PM, Ryosuke Niwa wrote:

 I think 5px is way too small.  Maybe 7 or 8 at least but even those are 
 really hard to read in high-resolution displays.  See demo.
 
 - Ryosuke
 
 On Wed, Nov 3, 2010 at 12:47 PM, David Hyatt hy...@apple.com wrote:
 That document also states:
 
 When the size of base characters is very small (for e.g. smaller than seven 
 points), ruby which is half the size, will be even more small and illegible. 
 In such cases where the size of base characters is very small, ruby is not a 
 suitable method of annotation. In those cases, consider other annotation 
 methods such as adding the reading in parenthesis immediately after the base 
 character.
 
 It also sounds like we need to special case Ruby elements and allow their 
 font sizes to go down to about 5px instead of 9px.  Anything lower, and 
 you're getting to the point where ruby was unsuitable (according to the text 
 above) anyway, since the base text was so small.
 
 I filed:
 
 https://bugs.webkit.org/show_bug.cgi?id=48942
 
 dave
 (hy...@apple.com)
 
 On Nov 3, 2010, at 2:29 PM, Yasuo Kida wrote:
 
 In printing the standard is 50% of the base text. For larger point sizes 
 like headings, the size of ruby is often smaller than 50%.
 
 http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#en-subheading2_3_3
 
 So, how about we default to 50% and see how they come out. Glyphs designed 
 for ruby are optimized for those small point sizes. It is possible on some 
 screen resolutions we might want to make it a bit bigger but as screen 
 resolution gets higher I think it makes more sense to stick to 50% following 
 the standard in printing.
 
 - kida
 
 On 2010/11/03, at 12:05, Eric Mader wrote:
 
 
 On Nov 3, 2010, at 8:56 AM, David Hyatt wrote:
 
 WebKit enforces a minimum font size of 9px when no explicit font size is 
 specified.  This means that the font for rt cannot fall below 9px if it 
 is relative to the user agent default.  It may be that we want to consider 
 modifying this minimum for ruby text and allow it to go below 9px though.  
 I'm not sure.
 
 Yes, that's probably what I'm seeing. I'm using default font size, which is 
 probably 12pt.
 
 If you make a really big Ruby (e.g., ruby style=font-size:96px and 
 then modify the font-size percentage on the rt, you should be able to 
 see it take effect.
 
 We should probably just study real-world Japanese examples to see how 
 small Ruby typically is allowed to get.  If it can go below 9px and still 
 be readable, we should perhaps consider allowing that.
 
 I'm sure the detailed spec. addresses this issue. I'll review it.
 
 In terms of excluding Ruby text from the overall line height, I don't 
 think the font-size of the rt is particularly relevant.  You just want 
 to hack the Ruby to turn the ruby text into overflow rather than having it 
 be part of the overall height of the inline-block.
 
 Of course. The website I was using has the line height set too tight for 
 correct display this way, and I just wanted to try a smaller size to see if 
 it looked better. OTOH, that site loads a style sheet that overrides the 
 ruby text font-size to 6pt, so I can't easily override it, and its' 
 probably displaying as 9pt anyhow.
 
 dave
 (hy...@apple.com)
 
 Regards,
 Eric
 
 On Nov 3, 2010, at 1:20 PM, Eric Mader wrote:
 
 Hi,
 
 As part of my work on ruby text enhancements, I'm implementing the option 
 of not counting the height of the ruby text in the overall line height. 
 As part of this, I wanted to play with changing the size of the ruby 
 text. I'm trying to do this by changing the following lines in 
 WebKit/WebCore/css/html.css:
 
 ruby  rt {
 display: block;
 font-size: 60%; /* make slightly larger than 50% for better 
 readability */
 text-align: center;
 text-decoration: none;
 }
 
 However, when I change the font-size: attribute to, say, 50%, I don't see 
 any difference in the size of the ruby text. (I even tried 25% just to be 
 sure). Is this value being set somewhere else?
 
 Regards,
 Eric Mader
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Any objections to switching to Xcode 3.2.4 or newer?

2010-11-03 Thread Darin Adler

On Oct 6, 2010, at 6:56 PM, Daniel Bates wrote:

 Please commit the updated Xcode project files.

I did that for most projects a while ago. It seems one or two of the files have 
since lost their developmentRegion string. I did it again for all the projects 
just now.

-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Size Of Ruby Text?

Thank you Ryosuke. This is a good demo. 5px is only barely legible and I agree 
it is too small. 6px is legible but not fun to read. 7px looks reasonable lower 
bound to me.

12pt text with 96dpi would translates to 16px, 50% ruby would be 8px. 10.5pt 
which is often used by printed books is 14px, 50% ruby would be 7px.

I do not think we should make the limit larger than 8px. The larger the ruby 
size gets the more often you need to put extra gaps in the base text, which 
makes the base text harder to read. See the example.

- kida

On 2010/11/03, at 14:01, David Hyatt wrote:

 Yeah, that demo makes me think maybe 9px is fine after all. :)
 
 dave
 
 On Nov 3, 2010, at 3:56 PM, Ryosuke Niwa wrote:
 
 I think 5px is way too small.  Maybe 7 or 8 at least but even those are 
 really hard to read in high-resolution displays.  See demo.
 
 - Ryosuke
 
 On Wed, Nov 3, 2010 at 12:47 PM, David Hyatt hy...@apple.com wrote:
 That document also states:
 
 When the size of base characters is very small (for e.g. smaller than seven 
 points), ruby which is half the size, will be even more small and illegible. 
 In such cases where the size of base characters is very small, ruby is not a 
 suitable method of annotation. In those cases, consider other annotation 
 methods such as adding the reading in parenthesis immediately after the base 
 character.
 
 It also sounds like we need to special case Ruby elements and allow their 
 font sizes to go down to about 5px instead of 9px.  Anything lower, and 
 you're getting to the point where ruby was unsuitable (according to the text 
 above) anyway, since the base text was so small.
 
 I filed:
 
 https://bugs.webkit.org/show_bug.cgi?id=48942
 
 dave
 (hy...@apple.com)
 
 On Nov 3, 2010, at 2:29 PM, Yasuo Kida wrote:
 
 In printing the standard is 50% of the base text. For larger point sizes 
 like headings, the size of ruby is often smaller than 50%.
 
 http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#en-subheading2_3_3
 
 So, how about we default to 50% and see how they come out. Glyphs designed 
 for ruby are optimized for those small point sizes. It is possible on some 
 screen resolutions we might want to make it a bit bigger but as screen 
 resolution gets higher I think it makes more sense to stick to 50% 
 following the standard in printing.
 
 - kida
 
 On 2010/11/03, at 12:05, Eric Mader wrote:
 
 
 On Nov 3, 2010, at 8:56 AM, David Hyatt wrote:
 
 WebKit enforces a minimum font size of 9px when no explicit font size is 
 specified.  This means that the font for rt cannot fall below 9px if it 
 is relative to the user agent default.  It may be that we want to 
 consider modifying this minimum for ruby text and allow it to go below 
 9px though.  I'm not sure.
 
 Yes, that's probably what I'm seeing. I'm using default font size, which 
 is probably 12pt.
 
 If you make a really big Ruby (e.g., ruby style=font-size:96px and 
 then modify the font-size percentage on the rt, you should be able to 
 see it take effect.
 
 We should probably just study real-world Japanese examples to see how 
 small Ruby typically is allowed to get.  If it can go below 9px and still 
 be readable, we should perhaps consider allowing that.
 
 I'm sure the detailed spec. addresses this issue. I'll review it.
 
 In terms of excluding Ruby text from the overall line height, I don't 
 think the font-size of the rt is particularly relevant.  You just want 
 to hack the Ruby to turn the ruby text into overflow rather than having 
 it be part of the overall height of the inline-block.
 
 Of course. The website I was using has the line height set too tight for 
 correct display this way, and I just wanted to try a smaller size to see 
 if it looked better. OTOH, that site loads a style sheet that overrides 
 the ruby text font-size to 6pt, so I can't easily override it, and its' 
 probably displaying as 9pt anyhow.
 
 dave
 (hy...@apple.com)
 
 Regards,
 Eric
 
 On Nov 3, 2010, at 1:20 PM, Eric Mader wrote:
 
 Hi,
 
 As part of my work on ruby text enhancements, I'm implementing the 
 option of not counting the height of the ruby text in the overall line 
 height. As part of this, I wanted to play with changing the size of the 
 ruby text. I'm trying to do this by changing the following lines in 
 WebKit/WebCore/css/html.css:
 
 ruby  rt {
 display: block;
 font-size: 60%; /* make slightly larger than 50% for better 
 readability */
 text-align: center;
 text-decoration: none;
 }
 
 However, when I change the font-size: attribute to, say, 50%, I don't 
 see any difference in the size of the ruby text. (I even tried 25% just 
 to be sure). Is this value being set somewhere else?
 
 Regards,
 Eric Mader
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org

Re: [webkit-dev] Size Of Ruby Text?

Does this work?

http://plexode.com/eval3/#ht=%3Cdiv%20style%3D%22font-size%3A16px%3B%22%3E%0A16px-8px%3A%3Cruby%3E%3Crb%3E国%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eくに%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E象徴%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eしょうちょう%3C%2Frt%3E%3C%2Fruby%3E%3Cruby%3E%3Crb%3E鬼門%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eきもん%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E方角%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eほうがく%3C%2Frt%3E%3C%2Fruby%3Eを%3Cruby%3E%3Crb%3E凝視%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A8px%3B%22%3Eぎょうし%3C%2Frt%3E%3C%2Fruby%3Eする。%3Cbr%3E%0A16px-9px%3A%3Cruby%3E%3Crb%3E国%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A9px%3B%22%3Eくに%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E象徴%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A9px%3B%22%3Eしょうちょう%3C%2Frt%3E%3C%2Fruby%3E%3Cruby%3E%3Crb%3E鬼門%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A9px%3B%22%3Eきもん%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E方角%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A9px%3B%22%3Eほうがく%3C%2Frt%3E%3C%2Fruby%3Eを%3Cruby%3E%3Crb%3E凝視%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A9px%3B%22%3Eぎょうし%3C%2Frt%3E%3C%2Fruby%3Eする。%3Cbr%3E%3Cbr%3E%0A%3C%2Fdiv%3E%0A%0A%3Cdiv%20style%3D%22font-size%3A14px%3B%22%3E%0A14px-7px%3A%3Cruby%3E%3Crb%3E国%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A7px%3B%22%3Eくに%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E象徴%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A7px%3B%22%3Eしょうちょう%3C%2Frt%3E%3C%2Fruby%3E%3Cruby%3E%3Crb%3E鬼門%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A7px%3B%22%3Eきもん%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E方角%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A7px%3B%22%3Eほうがく%3C%2Frt%3E%3C%2Fruby%3Eを%3Cruby%3E%3Crb%3E凝視%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A7px%3B%22%3Eぎょうし%3C%2Frt%3E%3C%2Fruby%3Eする。%3Cbr%3E%0A14px-9px%3A%3Cruby%3E%3Crb%3E国%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eくに%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E象徴%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eしょうちょう%3C%2Frt%3E%3C%2Fruby%3E%3Cruby%3E%3Crb%3E鬼門%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eきもん%3C%2Frt%3E%3C%2Fruby%3Eの%3Cruby%3E%3Crb%3E方角%3C%2Frb%3E%3Crt%20style%3D%22font-size%3A8px%3B%22%3Eほうがく%3C%2Frt%3E%3C%2Fruby%3Eを%3Cruby%3E%3Crb%3E凝視%3C%2Frb%3E%3Crt%20%20style%3D%22font-size%3A8px%3B%22%3Eぎょうし%3C%2Frt%3E%3C%2Fruby%3Eする。%3Cbr%3E%0A%3C%2Fdiv%3E%0Aohh=1ohj=1jt=ojh=1ojj=1ms=100oth=0otj=0cex=1


According to Choice of Size for Ruby Characters in Requirements for Japanese 
Text Layout:

 (note 2) When the size of base characters is very small (for e.g. smaller 
 than seven points), ruby which is half the size, will be even more small and 
 illegible. In such cases where the size of base characters is very small, 
 ruby is not a suitable method of annotation. In those cases, consider other 
 annotation methods such as adding the reading in parenthesis immediately 
 after the base character.

- kida

On 2010/11/03, at 15:21, Ryosuke Niwa wrote:

 Hi Yasuko,
 
 Somehow your example isn't working.  Could you copy  paste the HTML?
 
 - Ryosuke
 
 On Wed, Nov 3, 2010 at 3:11 PM, Yasuo Kida k...@apple.com wrote:
 Thank you Ryosuke. This is a good demo. 5px is only barely legible and I 
 agree it is too small. 6px is legible but not fun to read. 7px looks 
 reasonable lower bound to me.
 
 12pt text with 96dpi would translates to 16px, 50% ruby would be 8px. 10.5pt 
 which is often used by printed books is 14px, 50% ruby would be 7px.
 
 I do not think we should make the limit larger than 8px. The larger the ruby 
 size gets the more often you need to put extra gaps in the base text, which 
 makes the base text harder to read. See the example.
 
 - kida
 
 On 2010/11/03, at 14:01, David Hyatt wrote:
 
 Yeah, that demo makes me think maybe 9px is fine after all. :)
 
 dave
 
 On Nov 3, 2010, at 3:56 PM, Ryosuke Niwa wrote:
 
 I think 5px is way too small.  Maybe 7 or 8 at least but even those are 
 really hard to read in high-resolution displays.  See demo.
 
 - Ryosuke
 
 On Wed, Nov 3, 2010 at 12:47 PM, David Hyatt hy...@apple.com wrote:
 That document also states:
 
 When the size of base characters is very small (for e.g. smaller than 
 seven points), ruby which is half the size, will be even more small and 
 illegible. In such cases where the size of base characters is very small, 
 ruby is not a suitable method of annotation. In those cases, consider other 
 annotation methods such as adding the reading in parenthesis immediately 
 after the base character.
 
 It also sounds like we need to special case Ruby elements and allow their 
 font sizes to go down to about 5px instead of 9px.  Anything lower, and 
 you're getting to the point where ruby was unsuitable (according to the 
 text above) anyway, since the base text was so small.
 
 I filed:
 
 https://bugs.webkit.org/show_bug.cgi?id=48942
 
 dave
 (hy...@apple.com)
 
 On Nov 3, 2010, at 2:29 PM, Yasuo Kida wrote:
 
 In printing the standard is 50% of the base text. For larger point sizes 
 like headings,

Re: [webkit-dev] Size Of Ruby Text?