Gecko:Content Team Minutes: Difference between revisions

no edit summary
No edit summary
No edit summary
Line 1: Line 1:
Last week's actions:<br>
Last week's actions:<br>
<ol>
<ol>
  <li>current team roster: bz, dbaron, jst, sicking</li>
   <li>who else should be included? bryner, peterv, mrbkap</li>
   <li>who else should be included? bryner, peterv, mrbkap</li>
   <li>&nbsp;how should we track our work? wiki.mozilla.org</li>
   <li>&nbsp;how should we track our work? wiki.mozilla.org</li>
Line 13: Line 14:
     <li>brendan: beware w3c compound doc whim-wham, consider xul2 as
     <li>brendan: beware w3c compound doc whim-wham, consider xul2 as
consolidated namespace, keep eye on "rich client app" platform
consolidated namespace, keep eye on "rich client app" platform
competitors.&nbsp; also, footprint, perf, web compatibility, etc.</li>
competitors. also, footprint, perf, web compatibility, etc.</li>
   </ul>
   </ul>
   <li>wyciwyg caching for javascript:
   <li>wyciwyg caching for javascript:
(<a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=206531">https://bugzilla.mozilla.org/show_bug.cgi?id=206531</a>)<br>
(https://bugzilla.mozilla.org/show_bug.cgi?id=206531)
   </li>
   </li>
   <li>document.open/write-after-close blows away state
   <li>document.open/write-after-close blows away state
(<a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=114461">https://bugzilla.mozilla.org/show_bug.cgi?id=114461</a>)<br>
(https://bugzilla.mozilla.org/show_bug.cgi?id=114461)
   </li>
   </li>
   <li>blazingly fast "Back" issues
   <li>blazingly fast "Back" issues
(<a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=274784">https://bugzilla.mozilla.org/show_bug.cgi?id=274784</a>)<br>
(https://bugzilla.mozilla.org/show_bug.cgi?id=274784)
   </li>
   </li>
   <ul>
   <ul>
Line 30: Line 31:
   </ul>
   </ul>
   <li>brendan, need help: E4X &lt;-&gt; DOM
   <li>brendan, need help: E4X &lt;-&gt; DOM
(<a class="moz-txt-link-freetext"
(https://bugzilla.mozilla.org/show_bug.cgi?id=270553)</li>
href="https://bugzilla.mozilla.org/show_bug.cgi?id=270553">https://bugzilla.mozilla.org/show_bug.cgi?id=270553</a>)</li>
   <li>sicking: fix IndexOf quadratic growth
   <li>sicking: fix IndexOf quadratic growth
(<a class="moz-txt-link-freetext"
(https://bugzilla.mozilla.org/show_bug.cgi?id=240884)</li>
href="https://bugzilla.mozilla.org/show_bug.cgi?id=240884">https://bugzilla.mozilla.org/show_bug.cgi?id=240884</a>)</li>
   <ul>
   <ul>
     <li>sicking: will filling only in IndexOf pay off (don't want to
     <li>sicking: will filling only in IndexOf pay off (don't want to
Line 60: Line 59:
     <li>migration to XBL2 will help us clean up, but compatibility is
     <li>migration to XBL2 will help us clean up, but compatibility is
king for</li>
king for</li>
     <li>now we need to evaluate <a href="http://www.w3.org/TR/sXBL/">sXBL</a>
     <li>now we need to evaluate sXBL (http://www.w3.org/TR/sXBL/)
and <a href="http://www.hixie.ch/specs/xbl/XBL2.html">XBL2</a> spec
and XBL2 (http://www.hixie.ch/specs/xbl/XBL2.html spec drafts</li>
drafts</li>
     <li>bryner is gonna implement the sXBL/XBL2 extensions for binding
     <li>bryner is gonna implement the sXBL/XBL2 extensions for binding
attachment etc.</li>
attachment etc.</li>
Line 70: Line 68:
common content data structure, doesn't work well with HTML, etc.</li>
common content data structure, doesn't work well with HTML, etc.</li>
     <li>bryner: should we really keep XTF if XBL2 fixes everything?&nbsp;
     <li>bryner: should we really keep XTF if XBL2 fixes everything?&nbsp;
probably not, but are there things <a
probably not, but are there things XTF (http://www.croczilla.com/xtf) can do  
href="http://www.croczilla.com/xtf">XTF</a> can do that <a
that XBL2 (http://www.hixie.ch/specs/xbl/XBL2.html) can't?</li>
href="http://www.hixie.ch/specs/xbl/XBL2.html">XBL2</a> can't?</li>
     <li>bz: class attribute in HTML and XForms counterexample:
     <li>bz: class attribute in HTML and XForms counterexample:
nsIStyledContent has methods to query these, but it's not scriptable.&nbsp;
nsIStyledContent has methods to query these, but it's not scriptable.
But native-delegate goodness should address this</li>
But native-delegate goodness should address this</li>
     <li>bryner: another issue: binding to a namespaced attribute
     <li>bryner: another issue: binding to a namespaced attribute
Line 95: Line 92:
   </ul>
   </ul>
   <li>dbaron: it's hard not to leak with our toolkit (see
   <li>dbaron: it's hard not to leak with our toolkit (see
     <a class="moz-txt-link-freetext"
     https://bugzilla.mozilla.org/show_bug.cgi?id=283129)</li>
href="https://bugzilla.mozilla.org/show_bug.cgi?id=283129">https://bugzilla.mozilla.org/show_bug.cgi?id=283129</a>)</li>
   <ul>
   <ul>
     <li>brendan: maybe the ephemerality of XPConnect wrappers is the
     <li>brendan: maybe the ephemerality of XPConnect wrappers is the
Line 130: Line 126:
     <li>dbaron: could help dynamic theme switching if we change horses,
     <li>dbaron: could help dynamic theme switching if we change horses,
approaches</li>
approaches</li>
     <li>two issues, really: XUL and HTML.&nbsp; HTML iframe still loses
     <li>two issues, really: XUL and HTML; HTML iframe still loses
content when removed from doc<br>
content when removed from doc
     </li>
     </li>
   </ul>
   </ul>
   <li>jst: plugins should be owned by content nodes, not frames</li>
   <li>jst: plugins should be owned by content nodes, not frames</li>
   <li>sicking: 4% Tp win if we improve the mutation event
   <li>sicking: 4% Tp win if we improve the mutation event
implementation (<a class="moz-txt-link-freetext"
implementation (https://bugzilla.mozilla.org/show_bug.cgi?id=231676);
href="https://bugzilla.mozilla.org/show_bug.cgi?id=231676">https://bugzilla.mozilla.org/show_bug.cgi?id=231676</a>);
more to do with mutation events, for code cleanup as well as perf.</li>
more to do with mutation events, for code cleanup as well as perf.</li>
   <li>brendan: are there high-level design changes to improve perf,
   <li>brendan: are there high-level design changes to improve perf,
Line 147: Line 142:
     <li>incremental clean up event loop scheduling hacks</li>
     <li>incremental clean up event loop scheduling hacks</li>
     <li>dbaron: content sink is batching stuff up, parser is breaking
     <li>dbaron: content sink is batching stuff up, parser is breaking
things up; if content sink is "taking too long" -&gt; conflict</li>
things up; if content sink is "taking too long" -> conflict</li>
     <li>brendan: timers (bz: resolution bug due to condvar notify impl)
     <li>brendan: timers (bz: resolution bug due to condvar notify impl)
come up</li>
come up</li>
     <li>sicking: we're reflowing while loading too much, maybe to make
     <li>sicking: we're reflowing while loading too much, maybe to make
offsetTop etc. valid?&nbsp; KTHML better?</li>
offsetTop etc. valid? KTHML better?</li>
     <li>bz: reflows are flushed by offsetTop getter</li>
     <li>bz: reflows are flushed by offsetTop getter</li>
     <li>paint suppression is yet another hack to consider in global
     <li>paint suppression is yet another hack to consider in global
Line 204: Line 199:
     </li>
     </li>
   </ul>
   </ul>
   <li>Wiki URL: <a class="moz-txt-link-freetext" href="http://wiki.mozilla.org/wiki/Gecko:Content_Team_Minutes">http://wiki.mozilla.org/wiki/Gecko:Content_Team_Minutes</a></li>
   <li>Wiki URL: http://wiki.mozilla.org/wiki/Gecko:Content_Team_Minutes</li>


</ol>
</ol>
/be<br>
/be
<br>
Confirmed users, Bureaucrats and Sysops emeriti
419

edits