Re: [webkit-dev] Rename of selfOnlyRef to guardRef - ok if I change it back? (was Re: DOM tree traversal on detached nodes)

2012-06-15 Thread Roland Steiner
Sorry for the late reply, this thread flew under my radar.

I made the original name change, because I honestly was entirely confused
about the meaning of selfOnlyRef (it's done by Node on Document, so what
is self? Why is it needed?) - so I guess we'll have to agree to disagree
which one is clearer. ^_-

That said, I don't have a terribly strong opinion on this (and am not
actively developing WebKit ATM as well).
Also, as Morita-san mentioned, the scope of the implementation has changed,
too, so if you feel strongly about this, please go ahead! :)


Cheers,

- Roland

On Tue, Jun 12, 2012 at 12:14 PM, Hajime Morrita morr...@chromium.orgwrote:

 (from right address)

 +1 for the rename.
 The original idea to pull guardRef() mechanism up to TreeScope was
 abandoned
 and the size of intended responsibility of TreeScope has become much
 smaller than it originally was.
 So there is no reason to keep it even if the original intention wasn't
 clear.
 --
 morrita

 On Tue, Jun 12, 2012 at 12:05 PM, Ojan Vafai o...@chromium.org wrote:
 
 
  On Mon, Jun 11, 2012 at 6:43 PM, Kentaro Hara hara...@chromium.org
 wrote:
 
   I think selfOnlyRef() was a much clearer name.
 
  I would agree with the rename. (selfOnlyRef() might be removed if I
 could
  implement a reference counting that guarantees Reachable DOM nodes are
 kept
  alive, but it is still uncertain. Renaming would make sense to me.)
 
 
  Just a confirmation: In the following example, div.ownerDocument should
  return (not null but) iframe.contentDocument. Right?
 
 
  Correct.
 
 
 
  !DOCTYPE html
  htmlbodyiframe id=iframe/iframe
  script
  var iframe = document.getElementById(iframe);
  var div = iframe.contentDocument.createElement(div);  // div is not
 yet
  in the iframe's document tree
  document.body.innerHTML = '';
  console.log(div.ownerDocument);  // This should be
 iframe.contentDocument.
  There is no reference to nodes in the tree, but selfOnlyRef() keeps the
  reference to div.ownerDocument.
  /script
  /body/html
 
 
  On Tue, Jun 12, 2012 at 10:14 AM, Maciej Stachowiak m...@apple.com
 wrote:
 
 
  On Jun 11, 2012, at 6:06 PM, Maciej Stachowiak m...@apple.com wrote:
 
not a self-only reference (at some point renamed to guardRef).
 
  BTW I was able to find where it was renamed but not a good explanation
 of
  why. I think selfOnlyRef() was a much clearer name.
 
  The history seems to be that it was renamed when moved from Document to
  TreeScope (without explanation in the bug or ChangeLog, and apparently
  retaining it's self-only referencing behavior per comments):
 
 http://trac.webkit.org/changeset/82882
 https://bugs.webkit.org/show_bug.cgi?id=57689
 
  Then later it was moved back to Document but retaining the rename:
 
 http://trac.webkit.org/changeset/83123
 https://bugs.webkit.org/show_bug.cgi?id=57994
 
  Would anyone object if I renamed it back? Alternately, could the reason
  for the new name be documented somewhere?
 
  Regards,
  Maciej
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 
 
  --
  Kentaro Hara, Tokyo, Japan (http://haraken.info)
 
  ___
  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] Adding ENABLE_STYLE_SCOPED for a while

2011-11-20 Thread Roland Steiner
Hi all,

Since style scoped requires several patches to land fully, I intend to
add a ENABLE_STYLE_SCOPED flag for a while to avoid potentially shipping
half-done code.
See https://bugs.webkit.org/show_bug.cgi?id=72848 for the flag, and
https://bugs.webkit.org/show_bug.cgi?id=49142 for the master bug for style
scoped.

This flag will be off by default at first, switched on by default once
everything has landed, and be removed not so long thereafter provided no
serious issues crop up.


Cheers,

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


[webkit-dev] Landing style scoped with un-prefixed attribute name

2011-11-16 Thread Roland Steiner
[Resending this with different subject, since the original mail reportedly
got caught in spam filters]

On Wed, Nov 16, 2011 at 17:03, Ian Hickson i...@hixie.ch wrote:

 On Tue, 15 Nov 2011, Ryosuke Niwa wrote:
  On Sun, Nov 13, 2011 at 5:58 PM, Roland Steiner 
 rolandstei...@google.comwrote:
  
   A while ago there we had a discussion which direction style scoped
   should take, whether selectors should be scoped to the scoping
   element, or be global. At that time it was felt that 'scoped' should
   be prefixed until the discussion is resolved.
  
   Now, I have had implementation patches ready for a while already, and
   with Hixie agreeing that the spec should be changed in this regard (
  
 http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/07.html
 ),
   I wondered if it's ok for me to re-upload them in an un-prefixed
   'scoped' version, or whether folks would still prefer a '-webkit-'
   prefix after all.
 
  Has the spec changed and expected to be stable (i.e. no behavioral change
  in any foreseeable future)?

 I'm not aware of any new information coming to light since the e-mail in
 September. I haven't updated the spec yet, but forsee no reason why I
 would not do so in due course.

 --
 Ian Hickson   U+1047E)\._.,--,'``.fL
 http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
 Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'



Hi all,

Based on Hixie's mail above (referring to an earlier mail from September),
I would like to go forward and start landing style scoped in WebKit with
an un-prefixed attribute.

Should there be objections to this, please let me know!


Cheers,

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


Re: [webkit-dev] Quo vadis style scoped?

2011-11-15 Thread Roland Steiner
[Adding folks who commented on this before]

Cheers,

- Roland

On Mon, Nov 14, 2011 at 10:58, Roland Steiner rolandstei...@google.comwrote:

 Hi all,

 A while ago there we had a discussion which direction style scoped
 should take, whether selectors should be scoped to the scoping element, or
 be global. At that time it was felt that 'scoped' should be prefixed until
 the discussion is resolved.

 Now, I have had implementation patches ready for a while already, and with
 Hixie agreeing that the spec should be changed in this regard (
 http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/07.html),
 I wondered if it's ok for me to re-upload them in an un-prefixed 'scoped'
 version, or whether folks would still prefer a '-webkit-' prefix after all.



 Cheers,

 - Roland




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


[webkit-dev] Quo vadis style scoped?

2011-11-13 Thread Roland Steiner
Hi all,

A while ago there we had a discussion which direction style scoped should
take, whether selectors should be scoped to the scoping element, or be
global. At that time it was felt that 'scoped' should be prefixed until the
discussion is resolved.

Now, I have had implementation patches ready for a while already, and with
Hixie agreeing that the spec should be changed in this regard (
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/07.html),
I wondered if it's ok for me to re-upload them in an un-prefixed 'scoped'
version, or whether folks would still prefer a '-webkit-' prefix after all.



Cheers,

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


Re: [webkit-dev] Implementing style scoped

2011-09-29 Thread Roland Steiner
On Wed, Sep 14, 2011 at 1:26 AM, Roland Steiner rolandstei...@google.comwrote:

 On Mon, Sep 12, 2011 at 4:21 PM, Dimitri Glazkov dglaz...@chromium.orgwrote:

 Yeah. You're right. We should get Hixie to change the spec. I don't
 think we should implement currently spec'd behavior or change the
 name. That last option sounds exceptionally bad. Roland, can you post
 on that thread and request the spec change?


 Posted. :)



In those threads it seems we arrived at a preliminary agreement:

On Wed, Sep 28, 2011 at 2:49 PM, Ian Hickson i...@hixie.ch wrote:

 On Wed, 28 Sep 2011, Roland Steiner wrote:
 
  Hm, AFAICT Hixie's mail on www-style@ didn't raise any objections
  against the idea [of scoped selectors] itself, the discussion just
 revolves around what the
  exact syntax should be. Given that, what is the chance that we are able
  to go forward and declare selectors within style scoped as scoped, and
  leave the question how such selectors can breach the scoping as an
  orthogonal problem?

 Go for it. I recommend going with [@global] for now, too. Unless a better
 proposal gets put forward, I'll spec it in the near future. (So far
 nothing better has been put forward.)


In this light, are there any remaining objections to implement this with
'scoped' as the attribute name?


Cheers,

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


Re: [webkit-dev] Implementing style scoped

2011-09-13 Thread Roland Steiner
On Mon, Sep 12, 2011 at 4:21 PM, Dimitri Glazkov dglaz...@chromium.orgwrote:

 Yeah. You're right. We should get Hixie to change the spec. I don't
 think we should implement currently spec'd behavior or change the
 name. That last option sounds exceptionally bad. Roland, can you post
 on that thread and request the spec change?



Posted. :)

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


Re: [webkit-dev] Implementing style scoped

2011-09-09 Thread Roland Steiner
On Thu, Sep 8, 2011 at 6:51 PM, Ryosuke Niwa rn...@webkit.org wrote:

 Very excited for this feature!

 On Thu, Sep 8, 2011 at 2:28 PM, Roland Steiner rolandstei...@chromium.org
  wrote:

 As per discussion on
 http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032056.html,
 our implementation would diverge from the current HTML5 spec


 Why do diverge? It seems like we should at least prefix the attribute with
 webkit in the case spec changes in the future.


See above linked discussion for details. In the end we felt limiting the
selector matching to the scope is more natural, and - with the proposed
exception providued by :root and :scope - is more flexible.

However, naming the attribute 'webkit-scoped' may certainly be a good idea.


 Can we take these steps behind a flag given the attribute doesn't work
 properly without some steps?


I would prefer not to use a flag for the following reasons:

.) I already have the basic functionality working, with the exception of
scoped @keyframes and @font-face, so landing should not take a long time (I
am currently in the process of breaking the patch up, and adding more
tests).
.) There are quite a few changes that add parameters to functions, etc.,
which makes adding a flag ugly.


Cheers,

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


[webkit-dev] Implementing style scoped

2011-09-08 Thread Roland Steiner
Hi all,

After several discussions on the whatwg@ mailing list and others, we would
like to go forward with adding style scoped to WebKit.

Overview:

Style rules within style scoped only apply to the parent element of style
scoped (the scoping element), as well as descendants of it. Any other nodes
are unaffected. This allows authors to style specific parts of a page
without requiring ID prefixes. It also has potential performance benefits,
as scoped rules do not need to be evaluated outside their scope.

As per discussion on
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032056.html,
our implementation would diverge from the current HTML5 spec (
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-style-element)
in that we would match selectors only up to, and including, the scoping
element. E.g.,:

html
body
div id=bar class=X!-- A --
div id=foo   !-- B --
style scoped
div { ... } // applies to B, C, D
.X { ... } // applies to C
.Y { ... } // applies to D
.X .Y { ... } // doesn't match
#foo { ... } // applies to B
#bar { ... } // doesn't match
div div { ... } // applies to C, D
div div div { ... } // doesn't match
#foo div { ... } // applies to C, D
div #foo div { ... } // doesn't match
#bar .X { ... } // doesn't match
.X div { ... } // doesn't match
.X + div { ... } // apples to D
.X + .Y { ... } // apples to D
/style
div class=X!-- C --
/div
div class=Y!-- D --
/div
 /div
/div
div class=Y!-- E --
/div
/body
/html

If authors want to have a selector be able to bridge this barrier (but still
only apply to elements within the scope), we propose that the selector must
explicitly contain :root or :scope. E.g., with above HTML example:

:scope { ... } // applies to C
div:scope { ... } // applies to C
#foo:scope { ... } // applies to C
#foo:scope div { ... } // applies to C, D
#bar:scope div { ... } // doesn't match: match exceeds scope due to
presence of :scope, but A (#bar) isn't the scoping element
div :scope div { ... }  // applies to C, D: match exceeds scope due to
presence of :scope
:scope div div { ... } // doesn't match: no 2 nested divs beneath the
scoping element B
:root div { ... } // applies to B, C, D: match exceeds scope due to
presence of :root, but still doesn't apply to elements outside the scope
:root div div div { ... } // applies to C, D: match exceeds scope due to
presence of :root

However, this functionality (esp. implementation of :scope) would not be
part of the initial patch series.

The implementation plan is as follows:

1.) Add 'scoped' to HTMLStyleElement.idl and HTMLAttributeNames.in, as well
as adding the required plumbing for the attribute
2.) Implement registering with the scoping element. For efficient matching
it is necessary that an element can quickly discern whether or not it has
style scoped as direct child(ren).
3.) Implement the meat of the matching (see below)
4.) Add support for scoped @keyframes and @font-face

Note: https://bugs.webkit.org/show_bug.cgi?id=49142 already has a patch for
steps 1-3 that works as advertised. In order to make it easier to review, I
would just break it up into smaller chunks as outlined above.

ad 3.) Implementation of scoped selector matching works as follows:

.) scoped style sheet rules are contained in a separate map scoping element
address - RuleSet
.) add a field to ParentStackFrame that identifies the
closest ParentStackFrame that refers to a scoping element
.) during matching only check RuleSets that are thusly identified in
ParentStackFrame (plus a slow path that climbs the tree in case
ParentStackFrame isn't applicable), plus global rules
.) add a 'scope' parameter to the matching functions that identifies the
scoping element that limits the matching.

Note that with this implementation rules in scoped RuleSets that are not in
scope aren't even looked at. Also note that the actual selector data is NOT
modified for this. I.e., a selector in a scoped style sheet is not different
from a global selector. This has several benefits:

.) no updating necessary if a style element is inserted or removed from
the document, nor when the 'scoped' attribute is set/unset.
.) paves the way for a trivial implementation of a similarly scoped
querySelector[All].
.) for components: several component instantiations can re-use the same
template style sheet without the need to clone its rules.


Please let me know your thoughts,

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


Re: [webkit-dev] Parallel CSS styling

2011-06-07 Thread Roland Steiner
On Wed, Jun 8, 2011 at 7:54 AM, Ojan Vafai o...@chromium.org wrote:

 However, many of the performance improvements we can make to the
 single-threaded approach are limited in scope or have other trade-offs. For
 example, if I understand https://bugs.webkit.org/show_bug.cgi?id=49876
  correctly, it only applies during parsing and uses 16 more bytes per
 RuleData. On some sites (e.g. gmail) that have 30k RuleDatas, that's a
 ~500k memory hit without much performance benefit. It's a great change for
 some sites, but it's a significant cost for others.


The point of trade-offs is of course very valid. But rummaging around that
part of the code myself, that particular linked patch should actually save
quite a bit of matching time: it does a quick'n'dirty comparison against a
bloom filter (comparing hashes of IDs/classes/tags of selector parts vs.
hashes of stuff we encountered in ancestors) to quickly weed out selectors
that cannot possibly match - not all of them, but it should be a significant
subset of them.

As another possible avenue of improvements I wondered why selectors aren't
stored in a Trie data structure. In this way we could 1.) quickly discard
whole sub-branches of non-matching selectors on bottom-up matching, and 2.)
perhaps even keep track of sub-sets of potentially matching selectors during
tree-recursion in a top-down fashion.


Cheers,

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


Re: [webkit-dev] Proposal to Reorganize Position Classes

2011-02-02 Thread Roland Steiner
Just for context: Maciej and others had some feedback in the similar Rich
Text Editing Questions, Refactoring of Position Class thread from a year
ago (4/2/10). As an aside, I'm wondering if the general thoughts and
reservations about supporting positions inside :before/:after-generated
content and multiple ranges has changed in the meantime (?).

A few more comments (questions, rather) inline:


On Wed, Feb 2, 2011 at 11:51 AM, Ryosuke Niwa rn...@webkit.org wrote:

 Hi all,
 *
 *
 *While I'm not intending to write a patch for the following proposal
 anytime soon, I'd really like to get your feedback.*
 *
 *
 As you might all know, Position classes in WebCore need refactoring and
 cleanup.  Part of it is due to legacy editing positions that do many
 magics, and we're currently in the process of removing them (see the bug
 52099 http://webkit.org/b/52099).  However, even if we didn't have
 legacy editing positions, we still have rather clattered code base - there
 are many global functions in visible_units.cpp and VisiblePosition is used
 all over in WebCore/rendering - and reorganization of Position-related
 classes is needed (see the bug 52098 http://webkit.org/b/52098).

 I spent the last couple months to figure out what's the right solution and
 realized that there are generally two use cases of VisiblePosition:

- To differentiate upstream/downstream to express caret positions
- To iterate through editable regions to implement editing commands

 For the former use case, triggering layout or respecting editing boundary
 is not needed at all, and the use of VisiblePosition seems an overkill.  I
 concluded that these two use cases should be addressed by two different
 classes.

 So I propose to implement the following 3 classes in lieu of the existing
 Position and VisiblePosition:

- *DOMPosition* or *SimplePosition* - This class solely works on DOM,
and is agnostic of renderers and other parts of WebCore.  It's meant to be
used in utility functions and classes or passed along between renderers and
WebCore/dom.  It doesn't know anything about upstream or downstream.
- *RenderedPosition* - This positions is an enhanced version of the
current Position.  It represents every possible visible position and or DOM
position and communicates vocabularies between WebCore/rendering and
WebCore/editing.  It knows about line boundary and upstream/downstream but
it doesn't trigger a layout, doesn't canonicalize, and doesn't know 
 anything
about editing boundary.  Its life-time is tied to layout cycle, and needs 
 to
be re-created every time DOM mutation or style change occurs.  Many
functions in visible_units.cpp can belong to this class as member 
 functions.
 Furthermore, PositionIterator could be merged into this class because
RenderedPosition can cache pointers and other invariants as needed since
RenderedPosition's lifetime is tied to layout cycle.  It can also share 
 some
code with TextIterator as well.

 How does RenderedPosition know line boundaries and upstream/downstream if
it doesn't trigger layout?


- *EditingPosition* or *VisiblePosition* - This class is almost
identical to the existing VisiblePosition.  It knows everything DOMPosition
and RenderedPosition knows, and respects editing boundary.  A significant
difference with VisiblePosition is that this class remembers the editable
root element to which it belongs.  So when crossing editing boundary, it 
 can
figure out whether or not we're still inside the same root editable root or
not.  It also knows how to canonicalize itself so editing commands can
canonicalize positions as needed although canonicalization could be
optional.  I'm also not sure if this class should trigger a layout inside
its constructor like VisiblePosition does or not yet.

  A significant difference with VisiblePosition... - do you mean vs.
RenderedPosition or vs. the current VisiblePosition?




 The introduction of RenderedPosition is particularly useful in rendering
 engine because it allows to express any caret/insertion point position with
 a guarantee that it doesn't trigger a layout.


Not triggering layout is certainly a good point and something that should
bring quite a bit of performance. However, I wonder some of this
functionality shouldn't be factored out in a separate non-Position class
(say SelectionManager).


Cheers,

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


Re: [webkit-dev] Ruby Text Enhancements

2010-10-13 Thread Roland Steiner
Thanks a lot for the review! The patch has landed and should be a much
cleaner foundation for generated content (which may also have to be
overlapped).

Speaking of general ruby text enhancements: there is a new bug
https://bugs.webkit.org/show_bug.cgi?id=47596 regarding the ruby display
types. The previous consensus was that we shouldn't implement them (yet).
Furthermore, the expectation in that bug description would run contrary to
the spec anyway: setting rt to 'display: inline' should display it as ruby
text (rather than inline). Do you guys have any suggestions on this?

Cheers,

- Roland

On Thu, Oct 7, 2010 at 2:14 PM, Roland Steiner rolandstei...@google.comwrote:

 Seeing that this is progressing ad a quick pace, could I entice some kind
 reviewer to r+ my patch for bug
 https://bugs.webkit.org/show_bug.cgi?id=41040 before I get (another...)
 mid-air collision?

 ^_^; Roland


 On Wed, Oct 6, 2010 at 5:34 PM, Eric Mader ema...@apple.com wrote:


 On Oct 5, 2010, at 6:25 PM, David Hyatt wrote:

 On Oct 5, 2010, at 7:33 PM, Eric Mader wrote:


 On Sep 24, 2010, at 8:02 PM, David Hyatt wrote:

 This is a tough problem.  It seems like you have to get involved in the
 line layout code e.g., findNextLineBreak in order to really do the right
 thing.  findNextLineBreak uses an iterator that walks the objects, so it's
 easier to tell what text came before you and what text comes after you.  You
 can also tell whether or not that text will even fit on the line and
 possibly do the margin hacking there.


 I just did a prototype that checks for a RenderRubyRun in the isReplaced()
 code inside findNextLineBreak and calls a method on the RenderRubyRun that
 takes the last and the next object and sets negative margins by calling
 setMarginLeft() and setMarginRight(). I stepped through this code and it
 computes the correct margins, but the margins don't seem to take - the ruby
 doesn't overlap the surrounding text.

 Guessing that some other code is resetting the margins, I modified the
 code to cache the computed margins in the RenderRubyRun object and return
 the cached values through subclassed marginLeft() and marginRight() methods.
 With this change, the ruby displays as I would expect.


 It's probably RenderBlockLineLayout line 348 getting you in trouble (
 computeInlineDirectionPositionsForLine).  computeLogicalWidth is called
 again, and that will recompute the left/right margins and blow away the
 changes you made to them.  I have no idea why that call is there.  It should
 not be necessary, but maybe there's something subtle I'm missing.  You could
 try removing it, and see if that fixes the problem (it should).


 Yes, that did the trick! I haven't noticed any obvious problems with that
 line removed, but I haven't done much testing yet.

 dave
 (hy...@apple.com)


 Regards,
 Eric

 ___
 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] New Rich Text Editing Test suite

2010-10-06 Thread Roland Steiner
Hi Ryosuke,

looking closer at RTE2-AC_JF_TEXT-1_SC it seems to actually pass on my
Chrome Mac build (but it doesn't generate a br)?!):

Result:  div style=text-align: justifyfoo^bar/div
 Chromium7.0.547.0 (Developer Build ) WebKit534.10 V82.4.8
did you make any changes, or are you looking at a different build?

Cheers,

- Roland

On Fri, Oct 1, 2010 at 8:07 PM, Ryosuke Niwa rn...@webkit.org wrote:

 However, we pass JustifyLeft, JustifyRight, JustifyCenter even though we
 also add BR in those cases.  I don't quite understand the difference
 there...

 - Ryosuke


 On Thu, Sep 30, 2010 at 6:58 PM, Roland Steiner 
 rolandstei...@google.comwrote:

 On Fri, Oct 1, 2010 at 10:49 AM, Ryosuke Niwa rn...@webkit.org wrote:

 Mn... I realized something strange here.

 RTE2-AC_JF_TEXT-1_SC fails on WebKit TOT and the test is: JustifyFull on
 foo^bar.  However, it clearly works on WebKit when I test it manually.  It
 generates div style=text-align: justify;foobarbr/div.  I'm not sure
 why the test claims that WebKit fails on this particular test.


 That is probably one of the areas that needs discussion - the way the
 suite is set up currently, it doesn't allow for superfluous HTML elements.
 I.e., my guess is that it fails because of the extra br (ATM I don't have
 a TOT WebKit browser, so can't confirm for sure). I have added cases like
 this as acceptable (but not ideal) results for some tests, but not yet all
 of them (if we want to add this, then I guess I should implement some
 systematic way to check these rather than adding it by hand, though).

 Cheers,

 - Roland



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


Re: [webkit-dev] Ruby Text Enhancements

2010-10-06 Thread Roland Steiner
Seeing that this is progressing ad a quick pace, could I entice some kind
reviewer to r+ my patch for bug
https://bugs.webkit.org/show_bug.cgi?id=41040 before I get (another...)
mid-air collision?

^_^; Roland


On Wed, Oct 6, 2010 at 5:34 PM, Eric Mader ema...@apple.com wrote:


 On Oct 5, 2010, at 6:25 PM, David Hyatt wrote:

 On Oct 5, 2010, at 7:33 PM, Eric Mader wrote:


 On Sep 24, 2010, at 8:02 PM, David Hyatt wrote:

 This is a tough problem.  It seems like you have to get involved in the
 line layout code e.g., findNextLineBreak in order to really do the right
 thing.  findNextLineBreak uses an iterator that walks the objects, so it's
 easier to tell what text came before you and what text comes after you.  You
 can also tell whether or not that text will even fit on the line and
 possibly do the margin hacking there.


 I just did a prototype that checks for a RenderRubyRun in the isReplaced()
 code inside findNextLineBreak and calls a method on the RenderRubyRun that
 takes the last and the next object and sets negative margins by calling
 setMarginLeft() and setMarginRight(). I stepped through this code and it
 computes the correct margins, but the margins don't seem to take - the ruby
 doesn't overlap the surrounding text.

 Guessing that some other code is resetting the margins, I modified the code
 to cache the computed margins in the RenderRubyRun object and return the
 cached values through subclassed marginLeft() and marginRight() methods.
 With this change, the ruby displays as I would expect.


 It's probably RenderBlockLineLayout line 348 getting you in trouble (
 computeInlineDirectionPositionsForLine).  computeLogicalWidth is called
 again, and that will recompute the left/right margins and blow away the
 changes you made to them.  I have no idea why that call is there.  It should
 not be necessary, but maybe there's something subtle I'm missing.  You could
 try removing it, and see if that fixes the problem (it should).


 Yes, that did the trick! I haven't noticed any obvious problems with that
 line removed, but I haven't done much testing yet.

 dave
 (hy...@apple.com)


 Regards,
 Eric

 ___
 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] New Rich Text Editing Test suite

2010-10-04 Thread Roland Steiner
On Sat, Oct 2, 2010 at 5:14 AM, Ryosuke Niwa rn...@webkit.org wrote:

 I also noticed:

 RTE2-CC_FN:a_FONTf:a-1_SI fontname 'courier' y y y y FAIL font
 face=arialfoo[bar]baz/font font face=arialfoo[bar]baz/font font
 face=arialfoo/fontspanclass=apple-style-span style=font-family:
 courier[bar]/spanfont face=arialbaz/font Change existing font
 name to same font name, using CSS styling (should be noop)

 Isn't supposed to be fontname 'arial' instead?  There are 4 other tests
 below this one with the seemingly the same problem.


Whoops, the evils of copy-paste programming strike again! :p Fixed in the
last commit (not yet live).


On Sat, Oct 2, 2010 at 6:04 AM, Ryosuke Niwa rn...@webkit.org wrote:

 I think we shouldn't be hard-coding 18px here:

 {'value': '18px', 'pad': 'span style=font-size:
 large[foobarbaz]/span', 'expected': ['span style=font-size:
 large[foobarbaz]/span', 'span style=font-size:
 large[foobarbaz]/span'], 'command': 'fontsize', 'id':
 'FS:18px_SPANs:fs:l-1_SW', 'desc': 'Change existing font size to equivalent
 px size (should be noop, or change unit)'}

 The pixel font value of font-size: large is different depending on whether
 or not we're in strict/quirks modes and whether or not we're using fixed
 font (at least in WebKit and probably in Firefox).  We should be using the
 computed style value of the text instead.


The code to normalize units (colors and font sizes) is cribbed from the
original RichText suite. It does allow for some variation, but of course I'm
open for any suggestions. Esp. actually rendered font size (as opposed to
what's contained in the attributes/style) would be interesting, since that
may yet again be modified by inherited style. However, I'm not sure how to
portably test this across browsers.

Cheers,

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


Re: [webkit-dev] New Rich Text Editing Test suite

2010-10-04 Thread Roland Steiner
I don't have a ToT WebKit browser ATM, but I'll check once I updated and
compiled.

FWIW, this seems to be a regression anyways, since release Chromium (Chrome
6.0) at least passes all those tests, without extra br (?)


Cheers,

- Roland

On Sat, Oct 2, 2010 at 5:07 AM, Ryosuke Niwa rn...@webkit.org wrote:

 However, we pass JustifyLeft, JustifyRight, JustifyCenter even though we
 also add BR in those cases.  I don't quite understand the difference
 there...

 - Ryosuke


 On Thu, Sep 30, 2010 at 6:58 PM, Roland Steiner 
 rolandstei...@google.comwrote:

 On Fri, Oct 1, 2010 at 10:49 AM, Ryosuke Niwa rn...@webkit.org wrote:

 Mn... I realized something strange here.

 RTE2-AC_JF_TEXT-1_SC fails on WebKit TOT and the test is: JustifyFull on
 foo^bar.  However, it clearly works on WebKit when I test it manually.  It
 generates div style=text-align: justify;foobarbr/div.  I'm not sure
 why the test claims that WebKit fails on this particular test.


 That is probably one of the areas that needs discussion - the way the
 suite is set up currently, it doesn't allow for superfluous HTML elements.
 I.e., my guess is that it fails because of the extra br (ATM I don't have
 a TOT WebKit browser, so can't confirm for sure). I have added cases like
 this as acceptable (but not ideal) results for some tests, but not yet all
 of them (if we want to add this, then I guess I should implement some
 systematic way to check these rather than adding it by hand, though).

 Cheers,

 - Roland



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


[webkit-dev] New Rich Text Editing Test suite

2010-09-30 Thread Roland Steiner
 [Apologies if you have seen this already!]

Hi all,

As a lot of folks here can probably attest to (Hi, Ryosuke! ;) ), the
current state of rich text editing amongst various browsers is not ideal.
WebKit is better than most, but still not perfect, either.

In order to document this and provide a general overview of what works, what
plain doesn't, and what is incompatible, we are currently setting up a new
rich text editing test suite as part of the larger browserscope (
http://www.browserscope.org) framework. It is largely an extension and
generalization of the already existing RichText suite there. At the moment
we mainly focus on contentEditable and related functionalities in
JavaScript (i.e., execCommand(), queryCommandValue(), etc.), as well as
selection, but aim to extend this for user input and IME in the future, if
at all possible.

We hope this test suite will help in identifying the main problem areas (by
being a handy, friendly, colorful list of bugs), foster discussion about
different opinions on implementation, and thus in turn drive
interoperability between browsers. The goal is to reach a common set of
editing capabilities with well-defined behavior that is (even more) useful
for web authors.

A beta version can be accessed at
http://www.browserscope.org/richtext2/test (note
that being beta, the suite is not yet accessible from the main page at
http://www.browserscope.org). Please understand that we are still adding and
cleaning up tests, and details of the presentation. But at even at the
current, early stage it should give a good idea of the direction of the
suite. Indeed, as achieving consensus on the tests contained in the suite is
meant to be a community effort, it is bound to change and being extended
over time, as it solidifies based on contributions from all sides.

Since this can only benefit from the participation of as many folks as
possible, we would like to ask for input from everyone interested in the
area (even if it's just to grumble - I am happy to solidify past and current
grievances into new shiny red tests! ;) ). Thusly, for suggestions,
criticism, and general discussion on the suite and/or any tests therein,
please post a mail (or many!) at the browserscope mailing list at
browsersc...@googlegroups.com.


Best regards,

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


Re: [webkit-dev] New Rich Text Editing Test suite

2010-09-30 Thread Roland Steiner
On Fri, Oct 1, 2010 at 10:27 AM, Ryosuke Niwa rn...@webkit.org wrote:

 Great.  I'm getting get 500 on the results page but is this because it's
 still beta?


Good question - shouldn't happen. Have to ping Lindsey to see what the
problem is... :(

Cheers,

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


Re: [webkit-dev] New Rich Text Editing Test suite

2010-09-30 Thread Roland Steiner
On Fri, Oct 1, 2010 at 10:49 AM, Ryosuke Niwa rn...@webkit.org wrote:

 Mn... I realized something strange here.

 RTE2-AC_JF_TEXT-1_SC fails on WebKit TOT and the test is: JustifyFull on
 foo^bar.  However, it clearly works on WebKit when I test it manually.  It
 generates div style=text-align: justify;foobarbr/div.  I'm not sure
 why the test claims that WebKit fails on this particular test.


That is probably one of the areas that needs discussion - the way the suite
is set up currently, it doesn't allow for superfluous HTML elements. I.e.,
my guess is that it fails because of the extra br (ATM I don't have a TOT
WebKit browser, so can't confirm for sure). I have added cases like this as
acceptable (but not ideal) results for some tests, but not yet all of them
(if we want to add this, then I guess I should implement some systematic way
to check these rather than adding it by hand, though).

Cheers,

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


Re: [webkit-dev] New Rich Text Editing Test suite

2010-09-30 Thread Roland Steiner
First Blood!

^_- Roland

On Fri, Oct 1, 2010 at 11:26 AM, Ryosuke Niwa rn...@webkit.org wrote:

 But thanks to your test suite, I noticed some very embarrassing fact:
 https://bugs.webkit.org/show_bug.cgi?id=46954

 - Ryosuke


 On Thu, Sep 30, 2010 at 6:58 PM, Roland Steiner 
 rolandstei...@google.comwrote:

 On Fri, Oct 1, 2010 at 10:49 AM, Ryosuke Niwa rn...@webkit.org wrote:

 Mn... I realized something strange here.

 RTE2-AC_JF_TEXT-1_SC fails on WebKit TOT and the test is: JustifyFull on
 foo^bar.  However, it clearly works on WebKit when I test it manually.  It
 generates div style=text-align: justify;foobarbr/div.  I'm not sure
 why the test claims that WebKit fails on this particular test.


 That is probably one of the areas that needs discussion - the way the
 suite is set up currently, it doesn't allow for superfluous HTML elements.
 I.e., my guess is that it fails because of the extra br (ATM I don't have
 a TOT WebKit browser, so can't confirm for sure). I have added cases like
 this as acceptable (but not ideal) results for some tests, but not yet all
 of them (if we want to add this, then I guess I should implement some
 systematic way to check these rather than adding it by hand, though).

 Cheers,

 - Roland



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


Re: [webkit-dev] Fwd: Ruby Text Enhancements

2010-09-27 Thread Roland Steiner
On Sat, Sep 25, 2010 at 3:02 PM, David Hyatt hy...@apple.com wrote:

 On Sep 24, 2010, at 6:56 PM, Eric Mader wrote:

 This method makes several assumptions that I'm not 100% sure are always
 safe:
 * That a RenderRuby object holds only 1 RenderRubyRun object.


 I believe you can have multiple RenderRubyRuns inside a single RenderRuby.


 http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-ruby-element

 The ruby element allows one or more spans of phrasing content to be marked
 with ruby annotations.


Yes - after the change for https://bugs.webkit.org/show_bug.cgi?id=41040, a
ruby run will basically contain:

[:before-generated content]? [RenderRubyRun]* [:after-generated
content]?

Where RenderRubyRun is an inline-block element with 1 RenderRubyBase and
(currently) 0-1 RenderRubyTexts - the latter may change to 0-n at some
point.

Thinking this further, I also believe that once you implement ruby overhang
for the edges of the ruby element it will really look strange unless you
also implement overhang and offsets between ruby runs within the same ruby
element - i.e., implement Jukugo-ruby. This then has implications on the
line-breaking code within a single ruby.

Finally, as yet another corner case that I forgot in my last mail: as
implied above note that you also have to consider the
:before/:after-generated content for overhang.

Incidentally, you'll also have to consider generated content for item 4) of
your initial list (over/under-lines on ruby).



Cheers,

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


Re: [webkit-dev] Ruby Text Enhancements

2010-09-21 Thread Roland Steiner
Great to see someone else interested in doing ruby implementation! :)

I did the original ruby implementation, so I'm very happy to help with any
questions/problems/issues (bugs? there are not bugs!). BTW, please note that
there is another ruby patch in the review pipeline:
https://bugs.webkit.org/show_bug.cgi?id=41040 (had to modify and re-submit
this one after in-flight clashes with another patch) that might affect the
implementation.

On Tue, Sep 21, 2010 at 3:12 AM, David Hyatt hy...@apple.com wrote:

 On Sep 17, 2010, at 8:07 PM, Eric Mader wrote:

  Hi,
 
  I'm working on making the following enhancements to Ruby Text:
 
  1) Implement the behavior of ruby-overhang:auto


Oh vey, that's ambituous! :)  There's so many corner cases I foresee on this
one that I was just too happy to postpone it when we originally discussed to
leave out CSS3 ruby stuff from the initial implementation, which is purely
based off HTML5 - including supporting multiple base/text pairs within a
single ruby, and line-breaking within the ruby.



  2) implement the behavior of ruby-line-stacking:exclude-ruby


Which way do you intend to implement this? AFAICT the current consensus
seems to go towards having ruby included by default rather than excluded.



  3) Add some Mac OS specific character properties to the ruby text
 
  4) Turn off the underline when the ruby text is in a link
 
  I've looked at the code enough to know that the layout or ruby text is
 done by the normal block stacking in BlockLayout. I'm guessing that I can do
 at lest the first two tasks by changing the RenderRuby code to report a
 different width and / or height for the ruby block. Does this seem like the
 right way to do what I want?


  Assuming for the moment that it is, I have some questions:
 
  1) What methods should I subclass to report the adjusted width and
 height?
 

 I'm very hazy on the Ruby implementation.  I believe it makes an
 inline-block with two block children vertically stacked, and then it uses
 text-align:center to center the ruby base.  If so, this behavior has to be
 preserved when the ruby text is wider than the base.


Yes, that's the basic layout for a single ruby text/base pair. Note that
multiple such pairs may be contained within a single ruby element (which
is normally an inline element, unless it's floated or positioned). A ruby
may also include renderers for :before and :after content, which are outside
of the inline-blocks for base/text pairs. This is implemented in the
aforementioned patch for 41040, which also fixes some issues with
RenderRubyAsBlock and supersedes the patch for 43722).


 I think a reasonable way to implement overhang therefore would be with
 negative margins applied to the ruby run.  This way the correct layout of
 the Ruby object is preserved, and the surrounding text will just naturally
 get pushed inside the Ruby object to overlap it.

 Basically you can compare the delta in width between the base and the text
 and then apply margins to either side of the ruby run based off how you want
 to overhang.


That's also what I'd suggest. However, there are the following additional
things to consider:

.) The margin on the left side may need to be reduced because of line start
(setting it to 0), or neighboring elements that reduce how much it can
overhand (larger text or other element, a neighboring ruby element,
etc.).

.) The same goes for the right margin - however, this one is vastly more
tricky, since the following elements are probably not yet layouted.
Depending on what follows (text you can overhang, stuff that turns out you
can't overhang, the line end) you might need to increase the projected width
of the whole ruby run, which in turn might push out following elements.
There might even be extreme cases where ruby text overhangs multiple
following objects if those are very small.

You also need to be careful caching any values inside used for this inside
the ruby, because whether a ruby text may/may not overhang (or by how much)
may change dependent on changes inside _neighboring_ elements.

Also, please note that currently the size of rt is set at 60% of the base,
which is different from the standard 50%. This was chosen because it
improves readability on (low dpi) screens. If you implement ruby overhang
properly, esp. for the purposes of CJK rendering (see
http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#en-subheading2_3_3), you may
want/need to reconsider this, or adjust your implementation to take the
difference into consideration.

 2) If the ruby text is wider than the ruby base and I report the width of
 the base as the width of the whole block will some of the ruby text get
 clipped, or will it all still draw?
 

 It would all still draw as long as you set up overflow correctly.   You can
 look for addLayoutOverflow methods.  I think you may be able to use negative
 margins for overhang though without altering your reported width.

  3) Ruby text is only allowed to overhang the base in 

Re: [webkit-dev] Ruby Text Enhancements

2010-09-21 Thread Roland Steiner
Hi Eric,

comments inline:

On Wed, Sep 22, 2010 at 6:57 AM, Eric Mader ema...@apple.com wrote:


 On Sep 20, 2010, at 9:52 PM, Roland Steiner wrote:

 Oh vey, that's ambituous! :)  There's so many corner cases I foresee on
 this one that I was just too happy to postpone it when we originally
 discussed to leave out CSS3 ruby stuff from the initial implementation,
 which is purely based off HTML5 - including supporting multiple base/text
 pairs within a single ruby, and line-breaking within the ruby.

 Yes, it's a bit scary. ;-) I don't think I could implement the whole thing
 at once, so I'm looking at doing a partial implementation. Maybe the first
 round would only check to be sure that the neighboring blocks aren't ruby
 blocks.


I would actually suggest cutting it down further and at first doing it only
where the neighbor is plain text - this should still catch 90% of the cases
where you'd want overhang and should vastly reduce the corner cases. You can
verify and compute this rather easily when layouting the ruby, and you'd not
need to worry about different glyph heights of neighboring inline elements,
or about replaced elements interfering. Overhang would be basically be the
minimum of: maximum overhang, or length of neighboring text run, or
available/remaining space on the line. The latter factor may also cause you
to need to break the ruby or move it to the next line altogether.


I'm looking at using a RenderOverflow object to implement this. Can you
 point me at any documentation for this class, other than what's in the code?
 I'm having some trouble sorting out what all the various rectangles used in
 conjunction with this object represent.


I have to say I'm not personally familiar with RenderOverflow, either
(haven't used it with ruby). Just judging from the description it stores
overflow rectangles for stuff that is actual content (layout overflow) and
stuff that is pure cosmetic rendering, such as shadows or reflections
(visual overflow). For ruby overhang you'd be looking at layout overflow in
principle (unless the overhang text also has shadows and stuff, which may
add to the visual overflow), AFAICT. But as I said, I'm not really an expert
here.


Cheers,

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


Re: [webkit-dev] Table hit testing

2010-06-02 Thread Roland Steiner
AFAICT you could have an arbitrary number up to the width or height of the
table, whichever is smaller, by combining row- and colspans - e.g. with 3
([v]aligns just to emphasize the overlapping):

table border=1tbody
trtdR1C1/tdtdR1C2/tdtd rowspan=3 valign=bottom\\/td/tr
trtdR2C1/tdtd rowspan=2 colspan=2 align=right
valign=bottom///td/tr
trtd colspan=3 align=right/td/tr
/tbody/table

- Roland

On Wed, Jun 2, 2010 at 8:58 AM, Fady Samuel fsam...@google.com wrote:

 Hi David,

 Just so I'm certain, there's no way for more than two cells to overlap in a
 single grid slot, is there?

 Thanks,

 Fady Samuel


 On Thu, May 20, 2010 at 4:43 PM, David Hyatt hy...@apple.com wrote:

 On May 20, 2010, at 3:38 PM, Fady Samuel wrote:

  So what are the rules for stacking here? do the cells stack in the order
 in which they appear in the HTML?
 

 Correct, although note that backgrounds paint behind foregrounds, and hit
 testing works the same way, so it's not as simple as saying that cell 7 is
 always above cell 5.  They're interleaved, so from bottom to top:

 Cell 5 background
 Cell 7 background
 Cell 5 foreground (the number 5 in this example)
 Cell 7 foreground (the number 7 in this example)

 That's why if you hover over the actual number 5 in that example it will
 light up, but if you're in the background area overlap, the number 7 will
 light up.

 http://www.w3.org/TR/CSS21/zindex.html

 Therefore you do have to know about all the cells at the position, since
 when you're in the foreground phase of hit testing, cell 7 will say Nope,
 you're not inside my foreground, and so you then need to check cell 5,
 which will say Yes, you are inside my foreground.

 The grid structure just isn't expressive enough.  It needs to be patched
 to track all cells in a given row/column instead of just the first one.

 dave
 (hy...@apple.com)



 ___
 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] Editing Meeting

2010-04-13 Thread Roland Steiner
I have to say I agree with Ryosuke that this requires more consideration
(see inline comments).

On Wed, Apr 14, 2010 at 6:35 AM, Ojan Vafai o...@chromium.org wrote:

 On Tue, Apr 13, 2010 at 11:13 AM, Eric Seidel e...@webkit.org wrote:

 - There is an issue where application does not behave as expected:
 a/a depending on the position of the caret into the tag, the
 behaviour is not the same.


 The more general point here is that web apps need control over where
 editing commands go (e.g. where text gets inserted or where Range.insertNode
 inserts the node). The common case is anchor tags, but there are apps with
 custom widgets (e.g. comments in Google Docs) that need different behavior.
 The way they do this in Firefox is to control where the selection is (e.g.
 set it to be inside/outside the anchor). This doesn't work in WebKit because
 we normalize to a VisiblePosition.


Up to now, we've been assuming that the solution is to add the same support
 as Firefox. The suggestion at this meeting was to instead approach this from
 a policy perspective since we don't want web apps to have to capture
 key/mouse events to make this work. That way, we keep the invariant that
 there is one VisiblePosition to each cursor position. So, instead, we'll
 propose adding CSS rules that control this.

 -webkit-selection-affinity-start: inside/outside
 -webkit-selection-affinity-end: inside/outside


There are 2 main issues I see with this approach:

   - User style sheets can be crafted to inadvertently or deliberately break
   web apps that rely on a specific setting


   - It creates rather many ambiguous cases, and some cases are impossible,
   e.g. with nested elements of the same type: ... span class=aspan
   class=a ... /span/span ... -- how can I wrap the inner span, but
   not the outer (e.g., to delete it)?


In general I'm not sure this is a good invariant to keep (even though I can
understand the desire for it). E.g., on the boundaries of, say, bold and
non-bold text I find it most intuitive that I continue typing bold if the
cursor came from the bold side (i.e., is still within the b element), and
type non-bold if the cursor came from the non-bold side (i.e., is outside
the b element). Implementing such doesn't seem possible with this scheme.

As mentioned in another post to webkit-dev, I'd rather prefer having the
ability to specify arbitrary (non-normalized!) ranges that are affected by
editing operations. E.g., adding a 4th optional parameter to execCommand:

execCommand(command, showUI, value, range): if the 4th parameter is
present it specifies the range the command operates on. Otherwise the
default is the current selection.

This would be straightforward (IMHO), non-ambiguous and also remove the
current necessity of futzing around with the selection state. Also,
technically this isn't mutually exclusive with the CSS-based proposal (and
adding such attributes may still be worthwhile to guide user-made
selections), but it obviates the need to rely on it.

Now this would probably require more up-front standardization discussions
compared to a vendor-specific CSS attribute, but being more generally useful
(IMHO) I'd expect it to be less controversial in the end (may well be wrong
here, of course).


- We talked about creating performance tests for the various DOM operations.


 The specific idea was that we care more about order of magnitude runtime
 than we do raw numbers. So we can do something much simpler than proper perf
 tests that require a reference build. Instead, we can have tests for
 specific actions with different values of n to make sure that an O(n) case
 doesn't become O(n^2).


Yes, that's a great idea!


 - We talked about deprecating position class, and getting rid of
 node, node offset pairs in the DOM.


 We'd like to remove node/offset pairs entirely from
 VisiblePosition/Position. Instead we'll have beforeNode, afterNode,
 beginningOfNode, endOfNode. The only exception is that we'll still need
 offsets for offsets into text nodes.


This is quite similar to my refactoring proposal I sent to the mailing list,
so I'd very much like to see this change and would be glad to implement/help
implementing it!

Just for clarification how this is meant:

   1. does this also remove the current virtual positions such as [img,
   1], i.e., beginningOfNode(node) == beforeNode(node.firstChild),
   endOfNode(node) == afterNode(node.lastChild) if a child exists, and
   beginningOfNode(node) == endOfNode(node) if the node is empty and there is
   no beforeNode/afterNode in such a case, OR
   2. this retains the current virtual positions, and beforeNode/afterNode
   are for such positions (e.g., [img, 0] and [img, 1]) and
   beginningOfNode/endOfNode are for regular positions (or vice versa)

I'd very much hope for 1.) here... ;)


Cheers,

- Roland
___
webkit-dev mailing list
webkit-dev@lists.webkit.org

Re: [webkit-dev] Rich Text Editing Questions, Refactoring of Position Classes

2010-04-07 Thread Roland Steiner
Thanks for the comments! Please find my replies inline:

On Tue, Apr 6, 2010 at 2:51 PM, Maciej Stachowiak m...@apple.com wrote:


 On Apr 1, 2010, at 10:43 PM, Roland Steiner wrote:

 .) When a selection that starts in a table and ends outside it is deleted,
 the current code drags the adjacent outside content into the table. To me
 this is counter-intuitive (text can be dragged in, but not between cells,
 and not back outside), and it's also contrary to the behavior of other
 editors (FireFox, TextEdit, Word, etc.). The behavior is, however, enshrined
 in various layout tests, so I wonder if there was/is a reason to implement
 it this way. As this behavior also complicates fixing other bugs I wanted to
 see whether there would be much opposition to changing it (i.e., to content
 outside of a table staying outside on a delete operation).

 Which layout tests? Do they reference bugs? We can study the bugs to see if
 they truly ask for the behavior being tested.


On Tue, Apr 6, 2010 at 3:39 PM, Justin Garcia justin.gar...@apple.com
 wrote:


 I think you're right except that if the table doesn't look like a table
 (like if it doesn't have any cell borders) its content can just look like
 any other set of paragraphs.  Content should be merged in those cases I
 think.  Off the top of my head I believe some Mail behavior depended on
 this.  You could check and see when those layout tests were checked in and
 bug titles from the corresponding ChangeLog entries might shed some light on
 this.


The following layout tests explicitly require outside content to be moved
into table cells:

editing/deleting/5032066.html
rdar://problem/5032066 Delete should work between To Dos

editing/deleting/delete-block-table.html  (updated multiple times, the
change marked with * is the same as for the above layout test)
rdar://problem/4622763 Deleting from beginning of paragraph following
a table deletes rather than selects the table
Setup for rdar://problem/4344550 Misspellings aren't marked after undo
delete
rdar://problem/4922367 WebView selectLine: followed by deleteBackward:
deletes TABLE element of following line
*   rdar://problem/5032066 Delete should work between To Dos
rdar://problem/5107422 TOT REGRESSION: Delete key fails to delete
text, and cursor disappears in Mail.app
REGRESSION (r19595): WebViewDidBeginEditingNotification not posted when
focusing with the mouse
updated some test results that were affected by Hyatt's fix
for rdar://problem/5208440 REGRESSION: Raw text needs to be pulled outside
of tables (13753)

editing/deleting/5206311-2.html
rdar://problem/5206311 Whitespace can't be removed when editing text
pasted into from web page


A quick and dirty fix also affected the following layout tests:

editing/deleting/5026848-2.html
editing/deleting/5026848-3.html
moving content into table cell doesn't seem to be the point of these
tests, just a side-effect

editing/deleting/5115601.html
mentions table cell, but point of the test doesn't seem to be
table-specific - moving content into table cell seems therefore a side
effect

editing/unsupported-content/table-delete-001.html
current result image contradicts the expectation described in the test
header, fix would create intended result

editing/unsupported-content/table-delete-001.html
current result seems to contain extraneous br, fix would remove it

editing/inserting/12882.html
unexpected image diff in editing region halo (not sure why)

editing/execCommand/5432254-2.html
ASSERTs (placeholder br seems to get deleted/pruned)


Hard to comment on this idea from such a high level view. I don't understand
 how EditingPosition is meant to be different from VisiblePosition. Is
 EditingPosition just a VisiblePosition that's also a place where you can
 edit? I don't understand how DOMPosition is different in intent from the
 current Position. I'm not sure you want the low-level class to based on
 RangeBoundaryPoint, since the latter has the ability to adjust in response
 to DOM changes, which I am not totally sure we want in this case.


The basic idea would mainly be to combine PositionIterator and Position into
one class EditingPosition (or just Position), focusing on performance,
and to move renderer-specific code into VisualPosition (which could be
(re-)named RenderedPosition for clarity). Apart from an IMHO clearer code
separation this should also help improving the handling of :before/:after
content renderers, which currently is buggy.

DOMPosition/RangeBoundaryPoint would continue to be just the bridge to
JavaScript code and not used in (most) editing code.


Non-contiguous selections suck as UI, except for special cases like
 selecting tables by column. I don't think they are a good way to highlight
 find results. I don't think you want to end up with a non-contiguous
 selection highlighting all results when you do a find.


I don't understand: Safari and Chrome both do basically exactly that (albeit

Re: [webkit-dev] Rich Text Editing Questions, Refactoring of Position Classes

2010-04-07 Thread Roland Steiner
On Wed, Apr 7, 2010 at 4:36 PM, Maciej Stachowiak m...@apple.com wrote:


 It's not clear to me how PositionIterator is the same concept as
 EditingPosition. The latter implies that it would only ever represent a
 position where you can edit. The former implies that it produces a sequence
 of positions (perhaps retaining additional state to be able to step
 forward/back efficiently). It also seems to me that it is useful to have a
 concept of a Position that is primarily optimized iteration.


Perhaps EditingPosition is not the best of names. The basic idea is that
we shouldn't need 2 different classes Position and PositionIterator and
convert back-and-forth between them.


I'm also still not clear on the proposed relation between EditingPosition
 and VisiblePosition. Does every EditingPosition have an associated
 VisiblePosition? How about vice versa? Is the mapping one-to-one?


That is a good question - it depends how we want to treat stuff like
:before/:after content, list items, and such. A renderer-based
VisualPosition could technically select/iterate/identify such content, but
wouldn't necessarily have a corresponding Editing/DOMPosition. OTOH, an
EditingPosition probably would always have an associated VisiblePosition (At
least off the top of my head I can't think of a case where the user can edit
stuff that isn't rendered). An EditingPosition with reflection or somesuch
could in theory have more than one VisiblePosition, but I think that's
getting awfully fanciful.

However, the immediate idea here is more one of code separation: to put the
code that operates on renderers into its separate class.


 Safari doesn't make this non-contiguous region a selection. It marks it
 with a visual highlight. Only the first hit is actually selected. This makes
 a big difference when doing a find in editable text - typing only overtypes
 the first hit, rather than replacing the non-contiguous selection.

 Being able to represent a non-contiguous region is interesting, but it
 would be UI hell to allow such a thing to actually act as the user
 selection, and to get copied and pasted.


FWIW Firefox seems to handle it fine, but I agree that it's probably not
used much in practice (apart from column selection as you mentioned). I'm
thinking more of feature-completeness vs. the HTML5 spec here, and the
aforementioned non-selection highlights.

But whether or not to add this should be a separate discussion.


  On Wed, Apr 7, 2010 at 3:53 AM, Justin Garcia justin.gar...@apple.com
  wrote:


 For example:

 divimg style=display:blockimg style=display:block/div

 [img1, 1] and [img2, 0] are different visually but would both be
 normalized to the same position under the above proposal.


 I think this is a great example and shows that normalizing [img, 0] to
 [parent-of-img, index-of-img] can probably only happen once styles and
 renderers are taken into account, which doesn't strictly contradict Darin's
 point though (?).


 I'm not sure how it implies that. Would you assign a real DOM position
 differently between the two styles?

 I think the real difference here is in affinity, i.e. whether the caret
 would be at the end of one line or the start of the next. However this
 doesn't affect the DOM parent and offset.


Yes, that's what I meant - the DOM Position itself should obviously not be
affected by styles/CSS. This however leads me to a clarification question of
my own:

The [img1, 1] in Justin's example would be an invalid position, no? Do you
mean that (the internal representation of) [img/block, 0] and [img/block, 1]
should render the caret at different positions (i.e., the start/left side
and end/right side of the block line, respectively)? Or did you mean the
case of 2 images (i.e., without a real internal visual position) on
different lines?


Thanks,

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


Re: [webkit-dev] Rich Text Editing Questions, Refactoring of Position Classes

2010-04-07 Thread Roland Steiner
On Wed, Apr 7, 2010 at 6:19 PM, Maciej Stachowiak m...@apple.com wrote:


 I'm not sure I understand that goal. It's pretty normal for an iterator
 type to be distinct from the type of thing it iterates over.
 vectorT::iterator is not the same as T, even though it iterates over Ts.
 It is also not the same as vectorT itself. I'm not familiar with the exact
 state of the editing code, but that's what I think of when I hear a
 suggestion to combine PositionIterator and Position.

 I'm also not clear on where the name Editing comes from. What is it about
 this kind of position that's related to editing? Is it only allowed to
 represent positions where editing can happen? If so, then it can't be a full
 replacement for either Position or PositionIterator, since those are used to
 represent non-editable locations. If it can represent even non-editable
 locations, then I wonder how it differs from your proposed DOMPosition -
 would it be just the support for fast iteration?


Yes, Editing seems a poor choice of term, let's stay with Position. I
guess my proposal (which is actually not all that radical, I think) boils
down to:

1.) remove explicit support for virtual positions from Position.

2.) PositionIterator seems to be very limited in usefulness and after step
1.) there doesn't seem to be a reason why Position itself couldn't be
optimized for iteration and fast access the same way as PositionIterator is,
removing the need for a separate PositionIterator class.

3.) If we do step 2.), then everything that requires an explicit (node,
offset) interface requires a separate class. This class already exists in
the form of RangeBoundaryPoint. RangeBoundaryPoint + those additional
methods are what I termed DOMPosition. Ideally, creation of a DOMPosition
would only be needed at the start and end of an editing operation as input
and result for JS.

4.) Bundle all code from Position and VisualPosition that operates on
renderers in VisualPosition and move code from VisualPosition that doesn't
operate on renderers back into Position. The resulting VisualPosition class
is based on renderers rather than nodes. Re-factor editing code that queries
renderers to use VisualPosition objects instead. (perhaps naming the class
RenderedPosition or somesuch might be clearer).


Could a VisiblePosition have more than one associated EditingPosition?


Right now I can't think of a circumstance where that could be the case (it
would basically mean a given renderer is associated with more than one
node).



 I think to correctly iterate over positions where editing can happen, you
 need to be aware of rendering. For one thing, you want to skip stuff that is
 not rendered. Are you imagining that EditingPosition would be purely DOM
 based? Would EditingPosition or VisiblePosition be the type of object that
 represents a place where you can put the caret?

 I understand and sympathize with your attempt to clean up editing concepts,
 but I am not getting a sense of clean separation here.


^_^; Perhaps that's because my proposal is not ambitious enough (and
discussing these exact points was what I was hoping for with my initial
mails):

In the initial version at least I probably would want to change as little
code as possible: DOMPosition as the bridge to JS, Position continuing to be
used for most of the current editing/selection logic, VisualPosition as
helper class, the interface to the renderers, etc.

So I guess the answer to where to store the caret position would at first
(continue to) be that VisiblePosition is used to discern the place where to
put it, but Position is used to actually store it (if that makes sense).

However, as you point out, much of the editing logic requires information
from the renderers. Ideally this would mean changing most logic to work on
renderers via VisiblePosition over time, leaving Position just as somewhat
of a husk between DOMPosition and VisiblePosition. This would also allow us
to neatly iterate over, and select, generated content (the question being if
we could actually make use of that). However, with renderers getting
destroyed and rebuilt constantly I'm not sure how far this is feasible.


Cheers,

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


Re: [webkit-dev] Rich Text Editing Questions, Refactoring of Position Classes

2010-04-05 Thread Roland Steiner
One additional question on position classes:

The current implementation allows for (and operates on) positions such as
[img, 0] - [img, 1] or [br,0] - [br, 1]. Is there a fundamental reason to
keep such positions within the internal representation rather than normalize
them to [parent-of-img, index-of-img(+1)] - round-tripping perhaps?


Cheers,

- Roland

On Fri, Apr 2, 2010 at 2:43 PM, Roland Steiner rolandstei...@google.comwrote:

 Hi all,

 As I am working on WebKit rich text editing these days, there are 2 issues
 that I would like to address. From a brief internal discussion both seem
 feasible and worthwhile, but since they involve changes to current code and
 behavior I wanted to ask the WebKit community in general, and the original
 authors of WebKit editing in particular, about your opinion:

 .) When a selection that starts in a table and ends outside it is deleted,
 the current code drags the adjacent outside content into the table. To me
 this is counter-intuitive (text can be dragged in, but not between cells,
 and not back outside), and it's also contrary to the behavior of other
 editors (FireFox, TextEdit, Word, etc.). The behavior is, however, enshrined
 in various layout tests, so I wonder if there was/is a reason to implement
 it this way. As this behavior also complicates fixing other bugs I wanted to
 see whether there would be much opposition to changing it (i.e., to content
 outside of a table staying outside on a delete operation).

 .) The current Position classes are IMHO rather unfocused in their
 implementation, with lots of special cases and magical behavior, that
 still is often incorrect (e.g., with text that has padding, margins, or
 :before/:after content). For ease of further development they would
 therefore benefit from refactoring. The idea would be to change the classes
 into something along the lines of:

 DOMPosition: based on the current RangeBoundaryPoint, working on node +
 offset, interfacing with JavaScript
 EditingPosition (or TypeablePosition): based on the
 current PositionIterator for fast iteration, with most of the code of
 Position except for code that queries renderers
 VisiblePosition: change to work on renderers rather than nodes (moving
 such code from the current Position into this class).

 with explicit, but not implicit, conversion between them. Similarly for
 Ranges.

 In addition, a refactoring could add (or at least allow for) non-contiguous
 ranges and allow editing operations to work on arbitrary ranges/positions
 rather than just the (single) selection, which again currently is a pain
 point. In the long run I would envision to extend the code to allow multiple
 selections (such as for concurrent editing, or highlighting of find results,
 etc.), but that probably needs to be discussed separately.


 It would be great if you could share your thoughts,


 Cheers,

 - Roland



 *
 *

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


[webkit-dev] Rich Text Editing Questions, Refactoring of Position Classes

2010-04-01 Thread Roland Steiner
Hi all,

As I am working on WebKit rich text editing these days, there are 2 issues
that I would like to address. From a brief internal discussion both seem
feasible and worthwhile, but since they involve changes to current code and
behavior I wanted to ask the WebKit community in general, and the original
authors of WebKit editing in particular, about your opinion:

.) When a selection that starts in a table and ends outside it is deleted,
the current code drags the adjacent outside content into the table. To me
this is counter-intuitive (text can be dragged in, but not between cells,
and not back outside), and it's also contrary to the behavior of other
editors (FireFox, TextEdit, Word, etc.). The behavior is, however, enshrined
in various layout tests, so I wonder if there was/is a reason to implement
it this way. As this behavior also complicates fixing other bugs I wanted to
see whether there would be much opposition to changing it (i.e., to content
outside of a table staying outside on a delete operation).

.) The current Position classes are IMHO rather unfocused in their
implementation, with lots of special cases and magical behavior, that
still is often incorrect (e.g., with text that has padding, margins, or
:before/:after content). For ease of further development they would
therefore benefit from refactoring. The idea would be to change the classes
into something along the lines of:

DOMPosition: based on the current RangeBoundaryPoint, working on node +
offset, interfacing with JavaScript
EditingPosition (or TypeablePosition): based on the
current PositionIterator for fast iteration, with most of the code of
Position except for code that queries renderers
VisiblePosition: change to work on renderers rather than nodes (moving
such code from the current Position into this class).

with explicit, but not implicit, conversion between them. Similarly for
Ranges.

In addition, a refactoring could add (or at least allow for) non-contiguous
ranges and allow editing operations to work on arbitrary ranges/positions
rather than just the (single) selection, which again currently is a pain
point. In the long run I would envision to extend the code to allow multiple
selections (such as for concurrent editing, or highlighting of find results,
etc.), but that probably needs to be discussed separately.


It would be great if you could share your thoughts,


Cheers,

- Roland



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


Re: [webkit-dev] Leading new-line in dataTransfer.setData

2010-03-23 Thread Roland Steiner
Hm, but the first line could also be a comment (starting with '#') which
Mozilla also skips. IOW, I read the spec as return the first line that is a
(valid) URL. But of course I could be convinced otherwise...

Cheers,

- Roland

On Tue, Mar 23, 2010 at 5:37 PM, Maciej Stachowiak m...@apple.com wrote:


 On Mar 23, 2010, at 1:01 AM, Roland Steiner wrote:

 Hi all,

 On the topic of dataTransfer.setData, there seems to be a small
 inconsistency between browsers when it comes to leading new-lines. e.g.,
 dataTransfer.setData(text/uri-list, \nhttp://foo;) followed by
 dataTransfer.getData(URL).

 Mozilla returns an empty string (see
 http://mxr.mozilla.org/mozilla1.9.2/source/content/events/test/test_dragstart.htmlline
  271), while e.g., Chromium returns 
 http://foo;.

 Now, the HTML5 spec says:

 If the format (after conversion to lowercase) is url, then the data
 associated with the text/uri-list format must be parsed as appropriate
 for text/uri-list data, and the first URL from the list must be returned.
 If there is no data with that format, or if there is but it has no URLs,
 then the method must return the empty string.

 Which I read that the Chromium result is correct (not surprisingly, since I
 wrote the code ;) ). However, inconsistency is never good, so what would you
 folks think about this (and what would be the correct Mozilla ML to raise
 this question)?


 text/uri-list is a newline-separated list, right? In which case the first
 URL in the list above is the empty string, and therefore Mozilla's behavior
 is right.

 Regards,
 Maciej


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


Re: [webkit-dev] Leading new-line in dataTransfer.setData

2010-03-23 Thread Roland Steiner
Hm, I guess I've been successfully convinced otherwise (i.e., patch
upcoming!)... ^_^;

- Roland

On Tue, Mar 23, 2010 at 5:53 PM, Maciej Stachowiak m...@apple.com wrote:


 On Mar 23, 2010, at 1:40 AM, Roland Steiner wrote:

 Hm, but the first line could also be a comment (starting with '#') which
 Mozilla also skips. IOW, I read the spec as return the first line that is a
 (valid) URL. But of course I could be convinced otherwise...


 It doesn't start with #. And I'm sure that if HTML5 meant valid absolute
 URL rather than URL it would say so.

 In any case, I think this aspect of the API is reverse-engineered from
 Mozilla, so if HTML5 and Mozilla do disagree, arguably it is HTML5 that's
 wrong and should be fixed. BUt in this case it doesn't look like it.


 Cheers,

 - Roland

 On Tue, Mar 23, 2010 at 5:37 PM, Maciej Stachowiak m...@apple.com wrote:


 On Mar 23, 2010, at 1:01 AM, Roland Steiner wrote:

 Hi all,

 On the topic of dataTransfer.setData, there seems to be a small
 inconsistency between browsers when it comes to leading new-lines. e.g.,
 dataTransfer.setData(text/uri-list, \nhttp://foo;) followed by
 dataTransfer.getData(URL).

 Mozilla returns an empty string (see
 http://mxr.mozilla.org/mozilla1.9.2/source/content/events/test/test_dragstart.htmlline
  271), while e.g., Chromium returns 
 http://foo;.

 Now, the HTML5 spec says:

 If the format (after conversion to lowercase) is url, then the data
 associated with the text/uri-list format must be parsed as appropriate
 for text/uri-list data, and the first URL from the list must be returned.
 If there is no data with that format, or if there is but it has no URLs,
 then the method must return the empty string.

 Which I read that the Chromium result is correct (not surprisingly, since
 I wrote the code ;) ). However, inconsistency is never good, so what would
 you folks think about this (and what would be the correct Mozilla ML to
 raise this question)?


 text/uri-list is a newline-separated list, right? In which case the first
 URL in the list above is the empty string, and therefore Mozilla's behavior
 is right.

 Regards,
 Maciej




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


Re: [webkit-dev] Troubles with Anonymous Blocks

2010-02-14 Thread Roland Steiner
[Sorry for the late answer, I've been on vacation the last few days]

Basically, by setting

virtual bool createsAnonymousWrapper() const { return true; }

the class specifies that it creates its own anonymous child wrapper objects
that are not run-off-the-mill anonymous wrappers. I.e., it prevents such
child objects from being (re-)used in ways you didn't anticipate/intend.
There are only a few places (two, IIRC), that query this function, so if you
grep for it, you should get a good overview quickly whether this should
affect your code or not.


Cheers,

Roland


On Wed, Feb 10, 2010 at 12:08 AM, Alex Milowski a...@milowski.org wrote:

 On Mon, Feb 8, 2010 at 9:42 PM, Roland Steiner rolandstei...@google.com
 wrote:
  Just a stab in the dark here, and without knowledge about recent changes
  that could have caused your code to break (so this could be wildly off).
 The
  difference between the 2 versions AFAICT is whether m_isAnonymous is set
 or
  not, which leads me to the question: have you properly
  overridden createsAnonymousWrapper() in the parent?

 I haven't overridden that method.  What does it do?


 --
 --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 mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Troubles with Anonymous Blocks

2010-02-08 Thread Roland Steiner
Just a stab in the dark here, and without knowledge about recent changes
that could have caused your code to break (so this could be wildly off). The
difference between the 2 versions AFAICT is whether m_isAnonymous is set or
not, which leads me to the question: have you properly
overridden createsAnonymousWrapper() in the parent?

Cheers,

Roland

On Tue, Feb 9, 2010 at 6:28 AM, Alex Milowski a...@milowski.org wrote:

 I've been struggling with odd issues with anonymous blocks that I don't
 quite
 understand.  For example, to build a fraction in MathML I wrap the
 numerator
 and denominator in an anonymous block:

   RenderBlock* row = new (renderArena()) RenderBlock(document());

 I then set border, padding, and text-align style properties on the style
 for
 that anonymous block.  These settings seem to have stopped working
 in the latest round of work.

 If I change the construction of the row wrapper to:

   RenderBlock* row = new (renderArena()) RenderBlock(node());

 which is backed by the 'mfrac' element, all the border/etc. style
 properties
 work.

 When I trace through with the debugger, the border properties seem to
 disappear from the style object when the node is the document node
 and the block is anonymous.

 Any ideas on what is happening?

 I see that there is little code that uses an anonymous blocks directly
 as I do.  Is there are a preferred way to do this?

 My intended design for fractions was:

 1. The mfrac is a inline-block with block flows for its children

 2. The numerator and denominator are blocks that stack vertically.

 3. The denominator has a border property for the fraction line
separator.

 4. These wrapper blocks for the numerator and denominator can
have arbitrarily complicated flows of their own.

 Currently, if I use the second construct above and use node() as
 the backing node for the block wrappers for the numerator and
 denominator, it almost works.  There seem to be situations where
 the border is drawn short of the overall width--which is a another
 problem I'm struggling with but may be unrelated to this issue.

 --
 --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 mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] ruby annotation layout tests

2009-11-12 Thread Roland Steiner
Hm, interesting - I have to admit I just now saw that most (all?) test that
use non-English text are marked as Skipped for Windows (i.e., are in
LayoutTests/platform/win/Skipped). Now, if there is a fundamental reason why
such tests can't just be re-baselined (rendering incompatibilities between
Windows versions perhaps?), then changing the tests in fast/ruby to simply
use English text may well be the more prudent solution after all.

Cheers,

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


Re: [webkit-dev] ruby annotation layout tests

2009-11-11 Thread Roland Steiner
Yes, that was the reasoning why I used Japanese for those tests.

- Roland

On Thu, Nov 12, 2009 at 3:40 AM, David Hyatt hy...@apple.com wrote:

 I think it's better if they are japanese text, since that's the primary use
 case for ruby.

 dave


 On Nov 9, 2009, at 6:19 AM, Andras Becsi wrote:

  Hello, I have a question about the following HTML5 ruby annotation (
 http://www.w3.org/TR/ruby/) layout tests:

 fast/ruby/ruby-empty-rt.html
 fast/ruby/ruby-length.html
 fast/ruby/ruby-run-break.html
 fast/ruby/ruby-runs-spans.html
 fast/ruby/ruby-runs.html
 fast/ruby/ruby-simple-rp.html
 fast/ruby/ruby-simple.html
 fast/ruby/ruby-trailing.html
 fast/ruby/rubyDOM-insert-rt.html
 fast/ruby/rubyDOM-insert-text1.html
 fast/ruby/rubyDOM-insert-text2.html
 fast/ruby/rubyDOM-insert-text3.html
 fast/ruby/rubyDOM-remove-rt1.html
 fast/ruby/rubyDOM-remove-rt2.html
 fast/ruby/rubyDOM-remove-text1.html
 fast/ruby/rubyDOM-remove-text2.html

 Is there an explicit need that the texts in these tests need to be
 japanese? Could they be changed to have english texts in them and add some
 tests that test if japanese fonts are supported correctly?

 Thanks in advance!
 Andras (bbandix)
 ___
 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] Calling all committers: The pending-commit list is overflowing

2009-10-20 Thread Roland Steiner
On Tue, Oct 20, 2009 at 1:56 PM, Adam Barth aba...@webkit.org wrote:

 1) Epic uber bugs that are incomprehensible.  For example:

 [...]

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


@_@ Whoops, didn't realize that these patches are still active. All ruby
work went to https://bugs.webkit.org/show_bug.cgi?id=28420 (not that that
makes the patches less incomprehensible... ^_-).

I disabled my patches in 3749. Sorry for the unnecessary workload!


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


Re: [webkit-dev] MathML Project - Interested?

2009-10-05 Thread Roland Steiner
Same here, I'm also very interested in the project, but unfortunately also
won't have too many spare cycles to contribute. I'll try to keep up and add
one or the other comment of dubious helpfulness, though.
Cheers,

Roland


On Tue, Oct 6, 2009 at 5:35 AM, Kenneth Christiansen 
kenneth.christian...@openbossa.org wrote:

 I cannot say that I will be using it soon, but I really like the
 project and think that it can become very important for MathML and the
 web in general.

 As a Qt developer, it would also open the door for our users to
 integrate math into their applications.

 Cheers,
 Kenneth

 On Mon, Oct 5, 2009 at 5:04 PM, Alex Milowski a...@milowski.org wrote:
  I'd like to work on this MathML project in conjunction with those of you
  who might be interested in using it in the near future.  I'd also welcome
  any help.
 
  If you are interested, even as an observer, let me know.

 --
 Kenneth Rohde Christiansen
 Technical Lead / Software Engineer
 Qt Labs Americas, Nokia Technology Institute, INdT
 Phone  +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
 ___
 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] Two Pass Layout?

2009-09-18 Thread Roland Steiner
Hi Alex,
I'm in the process of doing ruby layout, currently under review (reviewers:
*hint, hint*), where I had several of the same issues, albeit not quite as
severe as with MathML (in effect, one could see ruby as nothing than a
series of mover/munder operations). I'm not sure how far my experiences
can help you, but let me add some comments:

On Fri, Sep 18, 2009 at 4:45 AM, Alex Milowski a...@milowski.org wrote:

 I'd like to re-oriented the code I have to include an RenderMathOperator
 class
 that can stretch operators that stretchable and do something else for ones
 that aren't (e.g. curly brackets can be stretched but angle brackets can
 only
 be resized by font size to a certain maximum before they look strange).


Note that for correct rendering, even stacking braces need to change font
sizes from time to time, so that the overall impression of weight stays
proportionate. That is, even if you have stacking braces, their width may
change.
Also note that the DOM may be manipulated afterwards - nodes added or
removed, causing recalculations or even add/remove line breaks (so you need
to be careful when caching values).

As for calulations, adding special anonymous boxes to group stuff into
smaller chunks might help (not sure there is actually a need for such things
in MathML). OTOH, such boxes also adds complexity when it comes to DOM
manipulation.


 The consequence of this, as I've noted before, is that I somehow need
 to invalidate the line boxes for the containing inline-block for the
 mrow/mfenced.  I've tried this a number of ways but it seems that things
 go wrong when the mrow/mfenced contains certain kind of replaced
 content (e.g. inline-table).


Not sure I understand the requirements correctly, but can't you just nuke
the line boxes with deleteLineBoxTree() and have them rebuilt?


Cheers,

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


Re: [webkit-dev] Whitespace changes

2009-08-27 Thread Roland Steiner
On Fri, Aug 28, 2009 at 6:22 AM, Dirk Pranke dpra...@chromium.org wrote:


 As to the trailing whitespace issue, I'm actually with you on this
 one; I've never seen that mentioned or considered as a coding style
 guideline before this project, and am continually getting tripped up
 by it on Chromium's presubmit hooks. Why do we think that this
 particular rule is a good one? I much prefer just using 'diff -b' :)

 -- Dirk

 PS. Special thanks to anyone who can tell me how to configure Vim,
 Emacs, Visual Studio, and XCode how to automatically strip those
 spaces so that I don't get tripped up by this ...


Speaking as another voice from the newcomer camp, I'd actually much prefer
if we could have this particular part of the style guide (stripping of
line-end whitespace) somehow automated with the submit process.
Inadvertently adding such space is way too easy, and having to manually
remove it (even when using some sort of editor script, which one may forget
to run) seems a waste of time for something that should be easy to automate.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] NeverNullT

2009-07-28 Thread Roland Steiner
I definitely like the general idea, but I don't think a NeverNull template
is worth it in the general case, for the following reasons:

First, I don't hink you can catch even a meaningful subset of all cases of
NULL assignment at compile time. OTOH, writing a template class that wraps a
non-null pointer has its use mainly in order to annotate header files, and
to auto-insert the ASSERT. In cpp files it's just a cosmetic difference to
ASSERTs, and enforcing the use throughout would probably change far too much
code, and run into other cumbersome details in addition to the ones I
mention below.

OTOH in order to be consequent, one would also need to use NeverNullX in
return values, e.g.,

NeverNullfoo bar() const;

Implementing such a function would have to be conscious of the fact that a
NeverNullX must always be initialized. i.e., you cannot write

NeverNullfoo Baz::bar() const
{
NeverNullfoo returnValue;
... compute returnValue ...
return returnValue;
}

Similar cases may also arise in other cases, when initialization is
non-trivial. So either one must us a tailored implementation, or use plain
pointers for the main computation. Both are somewhat defeating the purpose,
since they cause additional overhead.

Second, I believe that even if NeverNullX is a POD class, such wrapping
classes tend to defeat some compiler optimizations that would be performed
on raw pointers otherwise, so I'd be surprised to not see any performance
degradations. Whether or not they are significant, I can't say.


- Roland


On Wed, Jul 29, 2009 at 8:55 AM, Adam Barth aba...@webkit.org wrote:

 On Tue, Jul 28, 2009 at 4:29 PM, Jozwiak, Johnjjozw...@qualcomm.com
 wrote:
  Isn't the C++ reference annotation
 
   char  x;
 
  tantamount to declaration of a pointer
 
   char * x;
 
  to whom NULL assignment, as detectable at compile time, is a compile-time
 error?

 I'm not sure what you mean by as detectable at compile time, but
 I've certainly fixed crashers that were caused by NULL references.
 Templates should give you stronger properties, although you might have
 to do some fancy footwork to make subtyping work correctly.

 Adam
 ___
 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] InlineBox::m_isSVG

2009-06-25 Thread Roland Steiner
Hi Dave,

thanks again for the feedback! I've now submitted a patch to bug #3749 with
a basic ruby implementation with all the changes discussed on the list.
(including the flag). Would be great if you could take time to review the
patch whenever you can spare the time.

Cheers,

Roland

On Tue, Jun 23, 2009 at 2:12 AM, David Hyatt hy...@apple.com wrote:

 On Jun 21, 2009, at 11:18 PM, Roland Steiner wrote:

  Hi Dave,

 as I will probably need to special-case height() for ruby InlineBox
 objects in the same way as is done for SVG boxes (still ironing out the
 details, though), making height() virtual was exactly my intent. I would
 have thought that the performance cost of a virtual call to height() would
 be offset by being able to remove the isSVG() condition inside (and later a
 potential isRuby() condition as well).

 Now if there are actual performance reasons for that bit and/or for having
 height() be non-virtual, then I may need to find another solution.

 Thanks,

 Roland


 You could probably just rename the m_isSVG bit to be something like
 m_calculatesHeight, and then the virtual method that height() calls when
 that is true could be renamed to be more general.

 dave
 (hy...@apple.com)


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


Re: [webkit-dev] InlineBox::m_isSVG

2009-06-21 Thread Roland Steiner
Hi Dave,

as I will probably need to special-case height() for ruby InlineBox objects
in the same way as is done for SVG boxes (still ironing out the details,
though), making height() virtual was exactly my intent. I would have thought
that the performance cost of a virtual call to height() would be offset by
being able to remove the isSVG() condition inside (and later a potential
isRuby() condition as well).

Now if there are actual performance reasons for that bit and/or for having
height() be non-virtual, then I may need to find another solution.

Thanks,

Roland

On Fri, Jun 19, 2009 at 4:50 PM, David Hyatt hy...@apple.com wrote:

 On Jun 18, 2009, at 9:38 PM, Eric Seidel wrote:

  Agreed.  That should just be a virtual call.  I don't see any reason
 for that to need to be a bit on the baseclass.  I do not think that
 changing ti to be a virtual call would cause a noticeable performance
 change.

 -eric



 You can test and see, but that bit was added as part of devirtualizing
 height().  Originally when I virtualized height() on InlineBoxes it caused
 about a 1% perf regression, so I tried to devirtualize as much as I could in
 order to fix the problem.  If you make isSVG() virtual again, then you will
 cause height() to make a virtual function call every time again, and will
 probably re-introduce at least part of the perf regression.

 It's not clear to me why the bit being there is relevant to Ruby?

 dave
 (hy...@apple.com)


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


[webkit-dev] InlineBox::m_isSVG

2009-06-18 Thread Roland Steiner
Hi all,

As I'll probably need to add some special handling for ruby in inline flow
boxes, I came across this flag InlineBox::m_isSVG. AFAICT it doesn't seem to
have a deep functionality (it seems to be always true for SVG boxes and
always false for non-SVG boxes). Now, in order to consolidate the code with
my intended changes, I wanted to replace this flag with a virtual function
call on InlineBox::isSVG().

However, before going ahead with this I wanted to ask whether I'm missing
something, or whether there are folks who are deeply attached to this bit
(for debugging purposes, perhaps?).

Cheers,

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


[webkit-dev] Simplified ruby design document

2009-06-10 Thread Roland Steiner
Hi all,

After the feedback on my previous design document on ruby text annotations
and the reservations that were expressed, I prepared a new, scaled-back
version. I'd greatly appreciate if you could provide further feedback:

http://docs.google.com/View?id=dcgd8hk6_2g7c6zzc6

Note: implementation of the features outlined in the proposal is already
basically finished (mainly needs further testing and cleaning up), but can
of course be amended if necessary.


Thanks,

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


[webkit-dev] Ruby design document

2009-06-03 Thread Roland Steiner
Hi all,

I am in the process of implementing ruby (text annotations, mainly used in
East-Asian text), and would welcome if folks could give me feedback on my
design document, esp. regarding the rendering/layouting:

http://docs.google.com/View?id=dcgd8hk6_0ccsw4td4


Thanks,

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


Re: [webkit-dev] Ruby design document

2009-06-03 Thread Roland Steiner
Hi Peter,

You're right, that was an oversight, I added the reference to the
introduction part, and highlighted the differences as you mentioned.

My current implementation aims to be forward-compatible with both HTML5 and
CSS3, which seems to be rather straightforward from the pure object model.
It allows for several runs as per the HTML5 spec, and some variations in the
positioning as per the CSS3 spec. I'm not currently implementing CSS3
complex ruby, line stacking or ruby overhang.

Thanks,

Roland

On Wed, Jun 3, 2009 at 2:17 PM, Peter Kasting pkast...@google.com wrote:

 On Wed, Jun 3, 2009 at 2:12 PM, Roland Steiner 
 rolandstei...@google.comwrote:

 I am in the process of implementing ruby (text annotations, mainly used in
 East-Asian text), and would welcome if folks could give me feedback on my
 design document, esp. regarding the rendering/layouting:

 http://docs.google.com/View?id=dcgd8hk6_0ccsw4td4


 Your doc mentions the CSS3 ruby specs, but not the HTML5 specs (e.g.
 http://www.whatwg.org/specs/web-apps/current-work/#the-ruby-element ).  It
 would be good to link to the HTML5 doc, and perhaps note differences between
 the specs (I suggest implementing HTML5 in any cases where HTML5 and CSS3
 differ).

 PK

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


Re: [webkit-dev] Ruby design document

2009-06-03 Thread Roland Steiner
[+Ian]

Hi Dave,

I just added all elements from both specs, as it was easy and
straightforward enough. Code-wise, the RubyBaseContainer  RubyTextContainer
objects don't add much complexity (the multiple runs within a single ruby
element from the HTML5 spec pose more of a challenge, tbh). Now, I don't
know of any concrete use cases, but I still left them in for the time being,
for the following, admittedly rather flimsy, reasons:

.) being able to have ruby text both in before and after positions seems
like it could be useful
.) it seemed useful to have a wrapping block element in case the input is
malformed, has extraneous rt elements, or tries to do cute tricks (e.g.,
adding line breaks). *)
.) the Firefox plugin honors them
.) there are several sites that detail how to use CSS inline-table to get
complex ruby rendering, so I thought that perhaps there are actual use cases
out there after all

*) If those elements are removed, the number of box model objects are
reduced, but the code required for layouting and error handling might get
rather more involved.

However, if the consensus is that we should rather take those objects out
(Ian Hickson doesn't seem to be a fan of complex ruby, either), then of
course I can remove them from the code. The resulting object model would
probably look like:

ruby : RenderInline or RenderBlock (inline-block)
ruby-run : RenderBlock (inline-block with inline children) - 1 or
more
ruby-base : RenderInline - InlineFlowBox - 1
ruby-text : RenderInline - InlineFlowBox - 0 or 1 (could even
allow 2, for both 'before' and 'after' positions)


Cheers,

Roland

On Wed, Jun 3, 2009 at 3:43 PM, David Hyatt hy...@apple.com wrote:

 On Jun 3, 2009, at 4:59 PM, Roland Steiner wrote:

  Hi Peter,

 You're right, that was an oversight, I added the reference to the
 introduction part, and highlighted the differences as you mentioned.

 My current implementation aims to be forward-compatible with both HTML5
 and CSS3, which seems to be rather straightforward from the pure object
 model. It allows for several runs as per the HTML5 spec, and some variations
 in the positioning as per the CSS3 spec. I'm not currently implementing CSS3
 complex ruby, line stacking or ruby overhang.


 It seems like the design could be simplified considerably if we just say
 we're not going to do complex ruby.  Given that it's not in HTML5 and that
 IE doesn't do it, is complex ruby something we even want to worry about?

 dave
 (hy...@apple.com)


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


Re: [webkit-dev] Ruby design document

2009-06-03 Thread Roland Steiner
Ok, in that case should I also remove the code and constants for the
complex-ruby-specific CSS3 properties and HTML 'span' attribute, or should I
leave them in the code (and they just get ignored)?

Cheers,

Roland


On Wed, Jun 3, 2009 at 5:15 PM, Maciej Stachowiak m...@apple.com wrote:


 On Jun 3, 2009, at 5:12 PM, Peter Kasting wrote:

 On Wed, Jun 3, 2009 at 5:04 PM, Roland Steiner 
 rolandstei...@google.comwrote:

 However, if the consensus is that we should rather take those objects out
 (Ian Hickson doesn't seem to be a fan of complex ruby, either), then of
 course I can remove them from the code. The resulting object model would
 probably look like:

 ruby : RenderInline or RenderBlock (inline-block)
 ruby-run : RenderBlock (inline-block with inline children) - 1 or
 more
 ruby-base : RenderInline - InlineFlowBox - 1
 ruby-text : RenderInline - InlineFlowBox - 0 or 1 (could even
 allow 2, for both 'before' and 'after' positions)


 Seems like it wouldn't be hard to add the complexity in later (as a second
 pass) if we decide there's value there; in the meantime, writing the
 simplest possible implementation has testing and code readability benefits.
  I suggest sticking with the simple stuff that's sufficient to do HTML5 as a
 first pas.  When everything is in, tested and working, you can evaluate if
 more complex support a la the current CSS3 spec is a good idea.  If so it'd
 probably make sense to get HTMLx (whatever x is by then, perhaps 6) to agree
 so that other browsers are all on board too.


 I had the same reaction. Handling simple ruby seems like a good first step,
 even if we decide later that we want to add complex support.

 Cheers,
 Maciej


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


Re: [webkit-dev] Ruby design document

2009-06-03 Thread Roland Steiner
Hi Dave,

thanks for the feedback! To answer some of the questions you raised:

.) There certainly is a demand for this feature in Japan, China, and other
countries. The only browser that natively supports ruby currently is IE, so
I would assume most of the pages that use ruby today are written at least
with IE in mind. Therefore, the base line would be compatibility with that,
which boils down to implementing the HTML5 spec.

There are also apparently still be some pages left that adhere to a very
early ruby draft (http://www.w3.org/TR/1999/WD-ruby-19990322/), but I'm not
sure it's worth extra work to try to support that (haven't looked at that in
great detail yet).

.) IE (at least IE8) honors 'float' and 'position' on ruby elements, and
also 'display:block' works as expected.

.) Multiple runs within a single ruby element are rendered correctly in IE
(which I would suppose is the original reason for their inclusion in HTML5).
IE also line-breaks those runs.


Cheers,

Roland


On Wed, Jun 3, 2009 at 5:39 PM, David Hyatt hy...@apple.com wrote:

 On Jun 3, 2009, at 7:33 PM, David Hyatt wrote:


 The CSS3 draft is clearly very incomplete and not ready for primetime, so
 the more I look at it, the more I'm thinking we should maybe just limit
 ourselves to an HTML5/IE-compatible implementation.



 In other words I'm thinking we should just make ruby the only way you can
 make these things, and not necessarily support the CSS stuff yet.  I am
 concerned about crashes related to crazy interactions of all these new ruby
 display types (every time we add new display types the render tree
 complexity goes up, since any element can implement the display type and be
 put inside any other display type).

 For example, I don't even think display:ruby should be the right way to
 make a ruby in CSS, since a ruby clearly can be either block-level or
 inline-level.  You need two display types and not just one.

 How the ruby box model works in CSS is woefully underspecified as well.

 For now we could just hardcode the creation of the specific renderers when
 the tag names are encountered.  This has the added benefit of allowing you
 to make a ruby inline or block by changing the display type.  I'd suggest
 testing in IE in fact to see what happens when you float/position a ruby or
 when you specifically put display:block on a ruby.

 dave
 (hy...@apple.com)





 ___
 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] Ruby design document

2009-06-03 Thread Roland Steiner
Addendum:

.) IE does NOT honor 'display: ruby'


Cheers,

Roland

On Wed, Jun 3, 2009 at 6:30 PM, Roland Steiner rolandstei...@google.comwrote:

 Hi Dave,

 thanks for the feedback! To answer some of the questions you raised:

 .) There certainly is a demand for this feature in Japan, China, and other
 countries. The only browser that natively supports ruby currently is IE, so
 I would assume most of the pages that use ruby today are written at least
 with IE in mind. Therefore, the base line would be compatibility with that,
 which boils down to implementing the HTML5 spec.

 There are also apparently still be some pages left that adhere to a very
 early ruby draft (http://www.w3.org/TR/1999/WD-ruby-19990322/), but I'm
 not sure it's worth extra work to try to support that (haven't looked at
 that in great detail yet).

 .) IE (at least IE8) honors 'float' and 'position' on ruby elements, and
 also 'display:block' works as expected.

 .) Multiple runs within a single ruby element are rendered correctly in
 IE (which I would suppose is the original reason for their inclusion in
 HTML5). IE also line-breaks those runs.


 Cheers,

 Roland



 On Wed, Jun 3, 2009 at 5:39 PM, David Hyatt hy...@apple.com wrote:

 On Jun 3, 2009, at 7:33 PM, David Hyatt wrote:


 The CSS3 draft is clearly very incomplete and not ready for primetime, so
 the more I look at it, the more I'm thinking we should maybe just limit
 ourselves to an HTML5/IE-compatible implementation.



 In other words I'm thinking we should just make ruby the only way you
 can make these things, and not necessarily support the CSS stuff yet.  I am
 concerned about crashes related to crazy interactions of all these new ruby
 display types (every time we add new display types the render tree
 complexity goes up, since any element can implement the display type and be
 put inside any other display type).

 For example, I don't even think display:ruby should be the right way to
 make a ruby in CSS, since a ruby clearly can be either block-level or
 inline-level.  You need two display types and not just one.

 How the ruby box model works in CSS is woefully underspecified as well.

 For now we could just hardcode the creation of the specific renderers when
 the tag names are encountered.  This has the added benefit of allowing you
 to make a ruby inline or block by changing the display type.  I'd suggest
 testing in IE in fact to see what happens when you float/position a ruby or
 when you specifically put display:block on a ruby.

 dave
 (hy...@apple.com)





 ___
 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] WebKit-Build

2009-05-29 Thread Roland Steiner
Hi Fred,

Could it be that you did the checkout from under the Windows command line
rather than from within CygWin? This messes it up, at least that was the
cause for a similar issue I encountered. Everything worked fine when I
re-did the checkout under CygWin. It's also the first time I see the link
you posted - that patch shouldn't be necessary AFAIK.
Also (someone correct me if I'm wrong), setting any windows environment
variable also shouldn't be necessary, provided you set up the include paths
in Visual Studio correctly. (The only environment variable you need is
WEBKIT_TESTFONTS if you run layout tests on Windows - a whole 'nother can of
worms).

The errors you list below are auto-generated files. It seems the scripts
that generate them haven't been run, probably due to some previous error
(could be linked to the above issue).


Cheers,

Roland

On Fri, May 29, 2009 at 12:36 PM, F S kaboota...@yahoo.com wrote:

 Hello,

 Sorry, my previous email was sent at the middle, do not know why.

 I have made some improvements that I like to share the findings, however it
 still does not build.

 Things I did:
 -  Added Environment Variables for INCLUDE, PATH and LIB to Windows
 environment to match VC++ setting
 -  Reading through google find out needed to change
 WebKit\WebCore\css\makevalues.pl file to fix a bug.
 (
 http://lists.macosforge.org/pipermail/webkit-unassigned/2009-May/109430.html
 )
 - Now the WebCore projects compiles with only 32 errors as opposed to 1000+
 errors.

 Below is the files it can not find.  I have run the webkit-update.  Do you
 know why these files are missing and where can I get them?

 MoveSelectionCommand.cpp
 c:\cygwin\usr\webkit\webcore\svg\SVGElement.h(29) : fatal error C1083:
 Cannot open include file: 'SVGNames.h': No such file or directory
 WMLNoopElement.cpp
 CSSStyleDeclaration.cpp
 Plugin.cpp
 ..\editing\DeleteButtonController.cpp(33) : fatal error C1083: Cannot open
 include file: 'CSSValueKeywords.h': No such file or directory
 HTMLInterchange.cpp
 CrossThreadCopier.cpp
 ..\bindings\js\JSNodeCustom.cpp(61) : fatal error C1083: Cannot open
 include file: 'JSSVGElementWrapperFactory.h': No such file or directory
 SQLResultSetRowList.cpp
 XMLNames.cpp
 c1xx : fatal error C1083: Cannot open source file:
 '..\..\webkitbuild\obj\webcore\derivedsources\XMLNames.cpp': No such file or
 directory
 JSElementCustom.cpp
 ..\bindings\js\JSElementCustom.cpp(44) : fatal error C1083: Cannot open
 include file: 'JSSVGElementWrapperFactory.h': No such file or directory
 SVGElementFactory.cpp
 c1xx : fatal error C1083: Cannot open source file:
 '..\..\webkitbuild\obj\webcore\derivedsources\SVGElementFactory.cpp': No
 such file or directory
 JSSVGElementWrapperFactory.cpp
 c1xx : fatal error C1083: Cannot open source file:
 '..\..\webkitbuild\obj\webcore\derivedsources\JSSVGElementWrapperFactory.cpp':
 No such file or directory
 XLinkNames.cpp
 c1xx : fatal error C1083: Cannot open source file:
 '..\..\webkitbuild\obj\webcore\derivedsources\XLinkNames.cpp': No such file
 or directory
 WMLElementFactory.cpp
 c1xx : fatal error C1083: Cannot open source file:
 '..\..\webkitbuild\obj\webcore\derivedsources\WMLElementFactory.cpp': No
 such file or directory

 *Thanks and regards,*
 *Fred
 *


 --- On *Fri, 5/29/09, F S kaboota...@yahoo.com* wrote:


 From: F S kaboota...@yahoo.com
 Subject: WebKit-Build
 To: webkit-dev@lists.webkit.org
 Date: Friday, May 29, 2009, 6:23 AM

Hello all,

 I am new in Webkit development and I need your help.

 I am trying to build webkit with no success, I have spent quite some time
 reading google for possible hints and have seen many posts with many people
 having the same problem (some were posted a year or two ago) but have not
 seen any solution yet.
 I appreciate your help and looking forward to contribute as soon as I get
 my feet on the ground.

 Some background regarding my problem.

 -  Problem I see when I build:
 *Project : warning PRJ0018 : The following environment variables were not
 found:
 $(PRODUCTION)
 *

 *I have followed step by step the build instructions from (**
 http://webkit.org/building/checkout.html*http://webkit.org/building/checkout.html
 *).*
 -  I installed VC Express and I am able to build successfully from VC
 Express (sample code)
 -  I visited useful link (
 http://blog.wrbsoftware.com/archive/2009/04/14/debugging-safari-on-windows.aspx
 ).
 -  I got the latest  Webkit code and I placed it under C:\cygwin\usr\webkit
 It seems to me that I still am not seeing some undocumented steps and I am
 hoping you might be able to point me to a solution.

 Thank you very much.

 Regards Fred




 ___
 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] Q on CSSStyleSelector::adjustRenderStyle(), render tree node ordering

2009-05-27 Thread Roland Steiner
Hi all,

As I am currently hacking on implementing ruby for WebKit, I came across 2
questions where I couldn't find a good answer in the code, and thus would
like to ask people more knowledgable than me:

Question #1: CSSStyleSelector::adjustRenderStyle (css/CSSStyleSelector.cpp)
changes the effectiveDisplay value of a node. Amongst other things:

// Mutate the display to BLOCK or TABLE for certain cases, e.g., if
someone attempts to
// position or float an inline, compact, or run-in.  Cache the
original display, since it
// may be needed for positioned elements that have to compute their
static normal flow
// positions.  We also force inline-level roots to be block-level.

I.e., basically, for positioned and floating elements it changes
INLINE_TABLE - TABLE, INLINE_BOX - BOX, everything else - BLOCK. Now, a
ruby is analogous to an inline block, or inline table. However, there is no
analogous block-level object for ruby. Therefore I wondered whether it
wouldn't be ok (or even better, read: less error prone) to generally just
wrap such objects into an anonymous block instead of changing the display
value (with an exception for positioned/floated table parts that are handled
after that point in the code).

Question #2: Is there code that would expect that the relative order of
objects in the render tree follows the relative order of the corresponding
nodes in the DOM tree (i.e., if DOM-node-B is after DOM-node-A then
render-node-B should also be after render-node-A, where after means in the
same order encountered when doing a depth-first search). Or am I worrying
too much and I can order the nodes in the render tree without regard for the
DOM tree?


Thanks,

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


Re: [webkit-dev] Q on CSSStyleSelector::adjustRenderStyle(), render tree node ordering

2009-05-27 Thread Roland Steiner
On Wed, May 27, 2009 at 6:37 PM, David Hyatt hy...@apple.com wrote:


Thanks a lot for your answers!

On May 27, 2009, at 8:21 PM, Roland Steiner wrote:

  Hi all,

 As I am currently hacking on implementing ruby for WebKit, I came across 2
 questions where I couldn't find a good answer in the code, and thus would
 like to ask people more knowledgable than me:

 Question #1: CSSStyleSelector::adjustRenderStyle
 (css/CSSStyleSelector.cpp) changes the effectiveDisplay value of a node.
 Amongst other things:

// Mutate the display to BLOCK or TABLE for certain cases, e.g., if
 someone attempts to
// position or float an inline, compact, or run-in.  Cache the
 original display, since it
// may be needed for positioned elements that have to compute their
 static normal flow
// positions.  We also force inline-level roots to be block-level.

 I.e., basically, for positioned and floating elements it changes
 INLINE_TABLE - TABLE, INLINE_BOX - BOX, everything else - BLOCK. Now, a
 ruby is analogous to an inline block, or inline table. However, there is no
 analogous block-level object for ruby. Therefore I wondered whether it
 wouldn't be ok (or even better, read: less error prone) to generally just
 wrap such objects into an anonymous block instead of changing the display
 value (with an exception for positioned/floated table parts that are handled
 after that point in the code).


 My own expectation is that if you float or position a ruby it would just
 stop being a ruby and turn into a normal block.  Maybe others disagree
 though.


Just to clarify in order to avoid misunderstandings: with ruby I meant the
whole ruby element, including the base text, not just the ruby
text/annotation part.

Thus converting ruby to a block is IMHO not satisfying, as positioning the
ruby would cause it to no longer render correctly (its content just gets
dumped).
Also,ruby style=float:left A rt B /rt/rubywould not render
as a ruby, butspan style=float:leftruby style=float:left A rt
B /rt/ruby/spanwould render correctly.



  Question #2: Is there code that would expect that the relative order of
 objects in the render tree follows the relative order of the corresponding
 nodes in the DOM tree (i.e., if DOM-node-B is after DOM-node-A then
 render-node-B should also be after render-node-A, where after means in the
 same order encountered when doing a depth-first search). Or am I worrying
 too much and I can order the nodes in the render tree without regard for the
 DOM tree?


 You cannot order nodes in the render tree without regard for the DOM tree.
  There is an assumption of document ordering in the RenderObject lists.
  Check out how newly created renderers from the DOM get inserted passing in
 previous renderers for example.


Thanks. Solution #2 (muck around with layouting) it is, then! ^_-


Cheers,

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