Difference between revisions of "Mozilla.dev.tech.layout - Friday September 29 2006"
(→Newsgroup summaries:mozilla.dev.tech.layout) |
m |
||
Line 7: | Line 7: | ||
=Announcements= | =Announcements= | ||
+ | |||
+ | No announcements for this week. | ||
=Discussions= | =Discussions= | ||
+ | |||
+ | *Discussion on how the Firefox 1.5.0.7 DOM generates XHTML inline elements using Wordpress. It was determined that the generated elements from Wordpress do not follow the WC3 guidelines in appendix C of XHTML 1.0. Although the W3 validation accepted the generated XHTML as valid, a bug identified within the HTML Working Group ignored the invalid elements. Details can be located at [http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/42e27d7b95193c53/81c1636a55a31474#81c1636a55a31474 layout confusion] | ||
+ | |||
+ | *Refactoring the nsHTMLReflowState(ComputeBlockBoxData, InitConstraints) and nsImageFrame::GetDesiredSize which uses NS_INRINSICSIZE, into the following method: | ||
+ | |||
+ | <pre> | ||
+ | /** | ||
+ | * Compute the size that a frame will occupy. Called while | ||
+ | * constructing the nsHTMLReflowState to be used to Reflow the frame, | ||
+ | * in order to fill its mComputedWidth and mComputedHeight member | ||
+ | * variables. | ||
+ | * | ||
+ | * The |height| member of the return value may be | ||
+ | * NS_UNCONSTRAINEDSIZE, but the |width| member must not be. | ||
+ | * | ||
+ | * @param aAvailWidth The available width into which the element is | ||
+ | * being placed (i.e., the width of its containing | ||
+ | * block). | ||
+ | * @param aMargin The sum of the left and right margins of the | ||
+ | * frame, including actual values resulting from | ||
+ | * percentages, but not including actual values | ||
+ | * resulting from 'auto'. | ||
+ | * @param aBorder The sum of the left and right border widths of the | ||
+ | * frame. | ||
+ | * @param aPadding The sum of the left and right margins of the | ||
+ | * frame, including actual values resulting from | ||
+ | * percentages. | ||
+ | * @param aShrinkWrap Whether the frame is in a context where | ||
+ | * non-replaced blocks should shrink-wrap (e.g., | ||
+ | * it's floating, absolutely positioned, or | ||
+ | * inline-block). | ||
+ | */ | ||
+ | virtual nsSize ComputeSize(nscoord aAvailWidth, nscoord aMargin, | ||
+ | nscoord aBorder, nscoord aPadding, | ||
+ | PRBool aShrinkWrap) = 0; | ||
+ | </pre> | ||
+ | |||
+ | :Details can be located at refactoring some of [http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/9bbd4ceea2b72d17/aa3c40d434499e2b#aa3c40d434499e2b nsHTMLReflowState]. | ||
+ | |||
+ | *Discussion on how to determine whether there is pending layout changes or reflows when using a popup. It was concluded that a frame model change is utilized within a popup, not a layout change. On the reflow branch, check the DIRTY and DIRTY_CHILDREN framestate flags. That won't help with pending style changes, but it'll work to detect cases when the popup or something in it needs to be reflown. Details can be located at [http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/dd6f6a3d6c8b1bad/f49d3694aa682f69#f49d3694aa682f69 frame reflow] | ||
+ | |||
+ | *Issues related to the ongoing implementation of MathML-in-HTML into Mozilla, which include: | ||
+ | |||
+ | :*Exposing the MathML implementation to tag soup. | ||
+ | :*CSS Matching rules. | ||
+ | |||
+ | :Details can be located at [http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/f05a4077a9eac39f/94d10105c7f627d7#94d10105c7f627d7 MathML-in-HTML5] | ||
=Meetings= | =Meetings= | ||
No meetings for this week. | No meetings for this week. |
Latest revision as of 18:26, 29 September 2006
Newsgroup summaries:mozilla.dev.tech.layout
September 23-29, 2006
Go to mozilla.dev.tech.layout on google groups.
Go to mozilla.dev.tech.layout on this wiki.
Announcements
No announcements for this week.
Discussions
- Discussion on how the Firefox 1.5.0.7 DOM generates XHTML inline elements using Wordpress. It was determined that the generated elements from Wordpress do not follow the WC3 guidelines in appendix C of XHTML 1.0. Although the W3 validation accepted the generated XHTML as valid, a bug identified within the HTML Working Group ignored the invalid elements. Details can be located at layout confusion
- Refactoring the nsHTMLReflowState(ComputeBlockBoxData, InitConstraints) and nsImageFrame::GetDesiredSize which uses NS_INRINSICSIZE, into the following method:
/** * Compute the size that a frame will occupy. Called while * constructing the nsHTMLReflowState to be used to Reflow the frame, * in order to fill its mComputedWidth and mComputedHeight member * variables. * * The |height| member of the return value may be * NS_UNCONSTRAINEDSIZE, but the |width| member must not be. * * @param aAvailWidth The available width into which the element is * being placed (i.e., the width of its containing * block). * @param aMargin The sum of the left and right margins of the * frame, including actual values resulting from * percentages, but not including actual values * resulting from 'auto'. * @param aBorder The sum of the left and right border widths of the * frame. * @param aPadding The sum of the left and right margins of the * frame, including actual values resulting from * percentages. * @param aShrinkWrap Whether the frame is in a context where * non-replaced blocks should shrink-wrap (e.g., * it's floating, absolutely positioned, or * inline-block). */ virtual nsSize ComputeSize(nscoord aAvailWidth, nscoord aMargin, nscoord aBorder, nscoord aPadding, PRBool aShrinkWrap) = 0;
- Details can be located at refactoring some of nsHTMLReflowState.
- Discussion on how to determine whether there is pending layout changes or reflows when using a popup. It was concluded that a frame model change is utilized within a popup, not a layout change. On the reflow branch, check the DIRTY and DIRTY_CHILDREN framestate flags. That won't help with pending style changes, but it'll work to detect cases when the popup or something in it needs to be reflown. Details can be located at frame reflow
- Issues related to the ongoing implementation of MathML-in-HTML into Mozilla, which include:
- Exposing the MathML implementation to tag soup.
- CSS Matching rules.
- Details can be located at MathML-in-HTML5
Meetings
No meetings for this week.