[webkit-dev] How to report iOS UIWebView WebKit issues

[Mustafizur Rahaman]

Hi All,

I am developing an application using UIWebView on iPad & I am seeing couple
of WebCore (element style related) crashes. The crashes happens randomly
(yet to narrow it down to exact use case), but the call stack is the same
in all crashes.

I want to know if bugs.webkit.org is the right place to log such issues? I
know I have to provide a test html (so that it is easier for anyone to
reproduce)along with other details, when I will log the issue.

Could any one please confirm?

Thanks,
Rahaman
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Regarding OpenVG

[Mustafizur Rahaman]

Hi All,

Some quick reference to the analysis we have done so far:

   - The master bug for OpenVG work was
   https://bugs.webkit.org/show_bug.cgi?id=33987 where except one, all the
   dependent issues were resolved, so we assumed the basic functionality is up
   and running...
   - We also found
https://bugs.webkit.org/show_bug.cgi?id=47475
while
   scrubbing bugilla for openvg related changes, where someone commented (
   https://bugs.webkit.org/show_bug.cgi?id=47475#c4 ) that the OpenVG
   upstreaming effort might have been abandoned, though we did not get this
   confirmation from anywhere else yet.
   - Also as per
   https://lists.webkit.org/pipermail/webkit-dev/2010-January/011253.html the
   backend functionality seems to be working except the build system is not yet
   public, but this was an older email anyhow.
   - So, as Smitha mentioned below, we tried to use the sample openvg
   implementation from Khronos (
   http://www.khronos.org/registry/vg/ri/openvg-1.1-ri.zip) & tried to build
   the WebKit with OpenVG enabled & came across various compilation issues.

Therefore, if any one can throw some light on the questions below..

   - Is the OpenVG upstreaming effort still in progress? What is the current
   status?
   - Any help as how to build the OpenVG code? If any one can help us, we
   can go further details about the issues we are facing either in #webkit or
   in the mailing list.

Thanks for the help in advance,
Regs,
Rahaman

On Fri, Jul 15, 2011 at 5:54 PM, smitha g  wrote:

> Hi,
>   I am trying to build the Webkit code on Windows with OpenVG enabled.
> I have used the openvg header files and lib of Kronos group but the build
> fails. Could you please let me know if OpenVG code(under the macro
> PLATFORM(OPENVG)) upstreamed is functional. If so, could you please let me
> know the build procedure with OpenVG enabled. Also, kindly let me know if
> the upstreaming efforts on OpenVG front have been discontinued.
>
>
> Thanks & Regards,
> Madadi Smitha
>
> ___
> 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] 194 bugs in pending-commit

[Mustafizur Rahaman]

On a similar note of bug cleanup, I have also seen lot of issues which are
still in Unconfirmed state, even though the bug analysis says either the
issue is not reproducible etc etc.

So, Is there a way to clean up such bugs so that they don't unnecessarily
come up in queries. What is the traditional procedure we follow in such
cases?

Thanks,
Rahaman

On Sun, Jun 19, 2011 at 10:18 AM, Eric Seidel  wrote:

> webkit-patch upload clears all flags when obsoleting a patch.  We
> could make it not clear r- if you like.  I know of no way to construct
> a query like http://webkit.org/pending-commit in our current bugzilla
> without clearing r+ on obsolete patches/closed bugs.  We clear flags
> (specifically r+) to make the life of those going through
> http://webkit.org/pending-commit easier (like sever folks tried to do
> this afternoon).
>
> Similarly, our current bugzilla doesn't automatically clear r? on
> closed bugs.  So we have webkit-patch clean-review-queue to do that.
>
> The history information for any bug is always easily accessed via the
> "history" link in the upper-right corner of a bug, like:
> https://bugs.webkit.org/show_activity.cgi?id=62114
>
> -eric
>
>
> On Sat, Jun 18, 2011 at 9:01 PM, Antonio Gomes 
> wrote:
> > IIRC, Mozilla's bugzilla can "hide" obsolete patches (?). If so, why can
> not
> > webkit's bugzilla?
> >
> > I actually do not like the way the review flags are cleared today only in
> > order to make the tools and pending-xxx pages happier. IMO the review
> flags
> > give much about the history of the bug. In that matter, I dislike
> > webkit-patch's ways of clearing "r-" flags of patches while it marks it
> as
> > obsolete and uploads a new one. Reason: an easy-to-see r-'ed patch is
> very
> > helpful to me to understand the chronological progresses in the bug.
> >
> > What is the reason for clearing r- flag while uploading a new one,
> instead
> > of only making it obsolete?
> >
> > On Sat, Jun 18, 2011 at 2:23 AM, Adam Barth  wrote:
> >>
> >> On Fri, Jun 17, 2011 at 11:13 PM, Peter Kasting 
> >> wrote:
> >> > On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth 
> wrote:
> >> >> 2) Mark the patch as obsolete / clear the review flag if we're not
> >> >> going to land the patch.
> >> >
> >> > Does the slash mean "do both"?  I
> >> > have https://bugs.webkit.org/show_bug.cgi?id=47036 on that list and
> the
> >> > only
> >> > r+ed patch on it is already marked obsolete.
> >>
> >> Yeah, Bugzilla kind of sucks.  That page isn't smart enough to hide
> >> the obsolete patches.  If you have EditBugs, you can run "webkit-patch
> >> clean-pending-commit", which will automatically remove the review
> >> flags from obsolete patches.  Eric and I have been meaning to having
> >> one of the bots do that periodically, but we haven't set that up yet.
> >>
> >> Adam
> >> ___
> >> webkit-dev mailing list
> >> webkit-dev@lists.webkit.org
> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
> >
> > --
> > --Antonio Gomes
> >
> > ___
> > 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] Expected behavior of "scrolling" attribute for IFrame element

[Mustafizur Rahaman]

>
> The real problem to fix would be not have scrolling tied to having or not
> scrollbars, as I see it.
>

Antonio, Do you mean we should scroll depending on the content size
irrespective of whether the scrollbar is shown or not.If so, that is the
current behavior anyway.

The other way I was thinking (not sure whether this is possible) if my
content size is larger (i.e. i need scrolling ), i should ignore the
"scrolling" attribute & show the scrollbar (this needs a change in the spec
as well). Will this behavior have any side effect?

Thanks,
Rahaman

On Tue, Jun 14, 2011 at 12:01 AM, Antonio Gomes  wrote:

>
> overflow:hidden divs are used to implement custom scrollbars.
>>
>
> That, by itself sounds likea hack :)
>
>
>> While find-in-page breaking wouldn't be too bad, breaking autoscrolling on
>> these sites would likely require us to rollback the change. Maybe we should
>> expose an attribute or CSS property to allow controlling this to give sites
>> a workaround?
>>
>>
> The real problem to fix would be not have scrolling tied to having or not
>> scrollbars, as I see it.
>>
>
> --Antonio Gomes
>
> ___
> 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] Expected behavior of "scrolling" attribute for IFrame element

[Mustafizur Rahaman]

Hi,
I have updated the comments discussed till now in the bug description. Let's
have the remaining discussion in bugzilla (
https://bugs.webkit.org/show_bug.cgi?id=61558 ) so that it helps to find the
proper solution for the issue.

Thanks,
Rahaman

On Mon, Jun 13, 2011 at 9:00 PM, Darin Adler  wrote:

> HTML5 defines this scrolling attribute. It defines it in terms of a CSS
> overflow property on the frame below. The value scrolling="no" turns into
> overflow: hidden. Such overflow areas should not be scrolled.
>
> As I understand it, generally speaking, if we have something like a find
> feature or autoscrolling code that scrolls outside the normal mechanism, it
> still should not scroll such an area and needs some other way to deal with
> content that is hidden by being off the edge of a scrollable area. This can
> happen with things like large margin values (particularly negative ones) as
> well as simply overflowing the space provided.
>
>-- Darin
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Expected behavior of "scrolling" attribute for IFrame element

[Mustafizur Rahaman]

Hi,

As per w3cschools (http://www.w3schools.com/tags/att_iframe_scrolling.asp ),
the scrolling attribute of an iFrame element is expected to behave as per
following
Attribute Values Value Description  auto Scrollbars appear if needed (this
is default)  yes Scrollbars are always shown (even if they are not needed)
no Scrollbars are never shown (even if they are needed)
My question is: When scrolling="no" & still if scroll bar is needed (i.e. if
the content is larger than the iframe.), what would happen if i drag the
content inside the iFrame? Will the iFrame content be scrolled OR would it
not allow the user to scroll?

This is w.r.t. https://bugs.webkit.org/show_bug.cgi?id=61558 that I am
currently investigating.

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

Re: [webkit-dev] Issue Analysis:48290 [HTML Canvas globalCompositeOperation]

[Mustafizur Rahaman]

Hi Darin,

Thanks for your detailed explanation. Initially we decided to remove the
string as well the enum to fix this issue. But Karthik's patch (we have
already submitted the patch in
https://bugs.webkit.org/show_bug.cgi?id=48290) caused a Chromium build
issue & then we found that this enum is used in
lot of other places. So, we were a little apprehensive about the side effect
of this fix.

Therefore, we submitted another patch where we are returning from the canvas
code itself if the compositing mode is "highlight". We are still waiting for
the review comments.

Similar issue (https://bugs.webkit.org/show_bug.cgi?id=48289 ) we have also
seen for "darker"/CompositePlusDarker (not a valid compositing mode any
more). Can we also remove this as well?

Thanks,
Rahaman

On Wed, Jun 1, 2011 at 9:51 PM, Darin Adler  wrote:

> On May 31, 2011, at 11:49 PM, Karthik wrote:
>
> > However, the following comment was mentioned in GraphicsType.h ("//
> Note: These constants exactly match the NSCompositeOperator constants of //
> AppKit on Mac OS X Tiger. If these ever change, we'll need to change the //
> Mac OS X Tiger platform code to map one to the other. "). So I am little
> unclear what is the purpose of this CompositeHighLight.
>
> We can remove that comment. It’s obsolete.
>
> I believe the “highlight” compositing mode used to be supported in canvas
> by WebKit on Mac, but hasn’t been for some time. There’s probably no harm in
> removing it now.
>
> The fact that the string is “not valid” in the specification isn’t what
> makes it OK to remove. Please remember that the canvas implementation in
> WebKit was the first and predates the specification by at least a year. But
> it’s almost certainly OK to remove this compositing mode because it hasn’t
> been implemented for quite a while.
>
> There’s still a slim chance that there is some content out there relying on
> “highlight” being a synonym for “source-over”, but it’s not likely.
>
> One side comment: I think the mapping from strings to the various graphics
> enums really belongs in the canvas code, not in the platform directory.
>
>-- Darin
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Question on font property value "inherit" in HTML Canvas

[Mustafizur Rahaman]

Hi,

I was just thinking if anyone could provide me some help for the issue
mentioned below so that I can proceed further to resolve this. If you need
further info/clarification, please let me know, I would be glad to provide
more details.

Thanks,
Rahaman.

On Fri, May 20, 2011 at 6:05 PM, Mustafizur Rahaman
wrote:

> Hi,
>
> I am analyzing the following issue
> https://bugs.webkit.org/show_bug.cgi?id=48575 (the attachment in the issue
> description contains multiple issues) & I was particularly looking into *
> http://w3c-test.org/html/tests/approved/canvas/canvas_text_font_001.htm*(Test-case
>  passes in FF but NOT working in Safari(5.0.3)/Winlauncher setup
> [r86221])
>
> After going through the HTML5 Canvas spec (
> http://www.w3.org/TR/2dcontext/#dom-context-2d-font), my understanding is
> that if any of inherit/initial/default are used in the font property
> assignment statement (e.g., "20px inherit" OR "inherit 20px"), then it must
> ignore the font value assignment & continue with the previous font value
> assigned. This is in contrast to the CSS2.1 specification which allows the
> usage of "inherit" (The values initial/default are reserved for future use).
> Is this understanding correct?
>
> After debugging CSSParser & CSSGrammer.y I have found that:
> => for normal HTML/CSS the code flows through CSSParser::parseSheet() =>
> cssyyparse() => CSSParser::parseValue()
> => for HTML5 Canvas, the code flows through CSSParser::parseDeclaration()
> => cssyyparse() => CSSParser::parseValue()
> In the CSSParser::parseValue(), the handling is same for normal HTML/CSS
> as well as for HTML5 Canvas, i.e., it is handling the "inherit" in the same
> way.
>
> However, if my understanding as mentioned above is correct, the handling
> within the parser should be different (reason: CSS2.1 spec & the HTML Canvas
> 2D Context spec expects "inherit" to be handled differently).
>
> Can somebody help share thoughts/perspective on this...
>
> Thanks,
> Rahaman
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Font Name

[Mustafizur Rahaman]

Hi,

When you are drawing  some text, you create a RenderText(RenderObject) which
has all the rendering info & the m_style of RenderText has the style info
required to render the text.

Let's consider the following style data I have in my html page

body.rahaman{
font:30px courier;
}

 Rahaman 

Once the HTMLTreeBuilder parses the token, it creates HTMLStyleElement &
CSSStyleSheet & then asks the CSSParser to parse the StyleSheet. From there
it comes to CSSParser::parseValue()=>CSSParser::parseFont() as the I have
only used font property

We create a FontValue (which contain all the attribute a font property can
have like style, size, variant, family etc=> in this font_family, you can
actually see the font name you have used ). In CSSParser::parseFont, we
populate the FontValue structure (you can find the font family name in
font->family), calls CSSParser::addProperty() where we create a CSSProperty
with the FontValue/CSSValue being passed & this property is being stored in
CSSParser::m_parsedProperties.

Then we call CSSParser::createStyleRule where we used the m_parsedProperties
mentioned before to create a CSSMutableStyleDeclaration & set this
declaration for the CSSRule.

We then create CSSStyleSelector and call CSSStyleSelector::styleForElement
for the root element. Here somehow (I don't have much details what happens
in berween but figured out that we retrieve the same
CSSMutableStyleDeclaration mentioned above) & call
CSSStyleSelector::applyProperty(). Here each StyleSelector has its
RenderStyle (m_style), where from we retrieve the FontDescription & add the
properties accordingly. On the other hand, each RenderObject (the
corresponding node in the RenderTree for a node in DOM tree) has
RenderStyle, which gets the value we retrieved above.

Finally we call GraphicsContext::drawText() passing the Font which we have
retrieved from the RenderStyle we dsicussed above.

I am not sure if this is what you were looking for, I just shared whatever I
knew of the related area. Please let me know if you need anything else.

Thanks,
Rahaman


On Fri, May 20, 2011 at 12:22 AM, Soheil Servati Beiragh  wrote:

> Hi
> I want to know after webkit parses the html file where does it save the
> font that is used for text? It definitely won't save a name for the font but
> there should be some kind of index or sth to tell the rendering engine which
> font is being used.
>
> Thanks in advance
>
> *Soheil Servati Beiragh*
> *PhD Candidate, ECE Department,
> *
> *Research Center for Integrated Microsystems,*
> *University of Windsor.*
> Room 268 Essex Hall
> 401 Sunset Avenue
> Windsor, Ontario
> Canada, N9B 3P4
> Phone: 519-253-3000 Ext 3396
> Email: serv...@uwindsor.ca
>
> ___
> 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] Question on font property value "inherit" in HTML Canvas

[Mustafizur Rahaman]

Hi,

I am analyzing the following issue
https://bugs.webkit.org/show_bug.cgi?id=48575 (the attachment in the issue
description contains multiple issues) & I was particularly looking into *
http://w3c-test.org/html/tests/approved/canvas/canvas_text_font_001.htm*(Test-case
passes in FF but NOT working in Safari(5.0.3)/Winlauncher setup
[r86221])

After going through the HTML5 Canvas spec (
http://www.w3.org/TR/2dcontext/#dom-context-2d-font), my understanding is
that if any of inherit/initial/default are used in the font property
assignment statement (e.g., "20px inherit" OR "inherit 20px"), then it must
ignore the font value assignment & continue with the previous font value
assigned. This is in contrast to the CSS2.1 specification which allows the
usage of "inherit" (The values initial/default are reserved for future use).
Is this understanding correct?

After debugging CSSParser & CSSGrammer.y I have found that:
=> for normal HTML/CSS the code flows through CSSParser::parseSheet() =>
cssyyparse() => CSSParser::parseValue()
=> for HTML5 Canvas, the code flows through CSSParser::parseDeclaration() =>
cssyyparse() => CSSParser::parseValue()
In the CSSParser::parseValue(), the handling is same for normal HTML/CSS as
well as for HTML5 Canvas, i.e., it is handling the "inherit" in the same
way.

However, if my understanding as mentioned above is correct, the handling
within the parser should be different (reason: CSS2.1 spec & the HTML Canvas
2D Context spec expects "inherit" to be handled differently).

Can somebody help share thoughts/perspective on this...

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

Re: [webkit-dev] Question on Inline element

[Mustafizur Rahaman]

>
> You can see that the  overflows the paragraph in both Firefox and
> WebKit.  This seems to be caused by the align="left", which I believe
> implies the CSS style "float: left;".  I suspect that floats do not get
> counted towards the height of a block, but I'd have to check.  I suspect
> that if we cleared the float (adding something with style="float: clear")
> after the  we would see the p (block) expand so that the img did not
> overflow.
>

Hi Eric,

You were right. If i make the example as style="float:none", now the
paragraph area counts for the image area too & below is what I have
debugged.

When image float=>Inside RenderBlock::layoutRunsAndFloats(), my BidiResolver
contain the RenderObject for Img. Now when it searches for next line break,
it finds that the float needs a separate line box (in
RenderBlock::LineBreaker::skipLeadingWhitespace), therefore it calculates
the layout for the img in positionNewFloatOnLine() & increment the resolver.

As a result when the calculation reaches in
RenderBlock::createLineBoxesFromBidiRuns, the BidiRunList I have received
from the resolver no more contain the image node, therefore the paragraph
area calculation is only done based on the text it contains.

When Image in NOT float=>As per the above call flow, in
RenderBlock::LineBreaker::skipLeadingWhitespace, it finds that it does not
need a separate linebox for img render, therefore it does not increment the
resolver. So, in RenderBlock::createLineBoxesFromBidiRuns() the BidiRunList
contain all the children of the paragraph including the image & the text, as
a result the paragraph area counts for the image area.

So, ther root cause of the problem is when for float image,
positionNewFloatOnLine() is called, it has to appropriately set the
paragraph framerect.

Thanks.

On Tue, May 17, 2011 at 11:48 PM, Eric Seidel  wrote:

>
>
> On Tue, May 17, 2011 at 4:12 AM, Mustafizur Rahaman  > wrote:
>
>> Hi Eric,
>>
>> Thanks for your patient & detailed answer :-) So based on your
>> explanation, I understand that a paragraph element can contain an image
>> (inline) & text (inline) element altogether.
>> Am i correct?
>>
>> If that is so, as per my understanding the m_framerect of Renderblock
>> corresponding to Paragraph element will contain both the image & text
>> element.
>> Is this understanding correct?
>>
>
> From RenderBox.h:
>
> private:
>
> // The width/height of the contents + borders + padding.  The x/y
> location is relative to our container (which is not always our parent).
>
> IntRect m_frameRect;
>
> So yes, I would expect that to include the rects of all kids, including the
> text and image.
>
> I wrote the below html to draw a border around the paragraph element, but
>> the border is drawn around the text element only as can be seen in Safari
>> browser too, which brings to the conclusion that the framerect calculation
>> of paragraph element is not taking into consideration the children image
>> element.
>> 
>> 
>> 
>> p.one
>> {
>> border-style:solid;
>> border-width:5px;
>> }
>> 
>> 
>>  > height="256" align="left">Subscribe
>> 
>
>
> A slightly modified example:
> 
> p { border: 5px solid black; }
> img { border: 2px solid red }
> 
>  align="left">text
>
>
> You can see that the  overflows the paragraph in both Firefox and
> WebKit.  This seems to be caused by the align="left", which I believe
> implies the CSS style "float: left;".  I suspect that floats do not get
> counted towards the height of a block, but I'd have to check.  I suspect
> that if we cleared the float (adding something with style="float: clear")
> after the  we would see the p (block) expand so that the img did not
> overflow.
>
>
>>
>> I have also debugged the WebKit code & found that while doing layout
>> calculation for Paragraph element, it goes inside
>> RenderBlock::layoutInlineChildren==> Inside this we are doing the layout
>> for each of the children. As per my understanding, the size of paragraph
>> element would be the largest of its children & I dont see any such
>> calculation. Could you please suggest where I should look to fix this issue
>> appropriately?
>>
>
> As far as I can tell, there is no issue to fix. :)  I suggest that you read
> the CSS 2.1 spec and this will all become much clearer.
>
> As to where the height of a block is calculated? I would have to dig
> around, but I would start with methods like computeContentBoxLogicalHeight The
> height is going to b

Re: [webkit-dev] Question on Inline element

[Mustafizur Rahaman]

Hi Eric,

Thanks for your patient & detailed answer :-) So based on your explanation,
I understand that a paragraph element can contain an image (inline) & text
(inline) element altogether.
Am i correct?

If that is so, as per my understanding the m_framerect of Renderblock
corresponding to Paragraph element will contain both the image & text
element.
Is this understanding correct?

I wrote the below html to draw a border around the paragraph element, but
the border is drawn around the text element only as can be seen in Safari
browser too, which brings to the conclusion that the framerect calculation
of paragraph element is not taking into consideration the children image
element.



p.one
{
border-style:solid;
border-width:5px;
}


 Subscribe


I have also debugged the WebKit code & found that while doing layout
calculation for Paragraph element, it goes inside
RenderBlock::layoutInlineChildren==> Inside this we are doing the layout for
each of the children. As per my understanding, the size of paragraph element
would be the largest of its children & I dont see any such calculation.
Could you please suggest where I should look to fix this issue
appropriately?

Thanks,
Rahaman
On Fri, May 13, 2011 at 11:25 PM, Eric Seidel  wrote:

>
>
> On Thu, May 12, 2011 at 10:52 PM, Mustafizur Rahaman <
> mustaf.h...@gmail.com> wrote:
>
>> So my question is
>>
>>- Can a paragraph element contain an image element=> the html spec
>>does not say NO.
>>
>> Yes.  There are two specs at play here.  HTML and CSS. Ignore anything
> prior to HTML5 as it was proscriptive rather than descriptive and does not
> match what browsers and web authors actually use!(aka ) is
> just an inline element.  (Like span or b or i, etc.) and flows with inline
> children per the CSS spec.  (See CSS 2.1).  So Paragraph, which is a block,
> can contain as many inline children as its little heart desires.  
> happens to be a "replaced" element, so it has intrinsic size (again see CSS
> 2.1).  Inline children (with the exception of inline blocks, which are
> blocks which flow as inlines) CANNOT contain box children (blocks are
> boxes), so for example  would be invalid and cause a
> special type of craziness called a "continuation", where the spans inline
> contents are split in two, wrapped in anonymous blocks, and the two
> anonymous wrappers and the P are all children off the parent instead of the
> P being a child of the span.
>
>
>>
>>- If we make the image element neither float/nor positioned, it
>>creates an anomynous block & everything is rendered properly. But I am not
>>sure whether that is the right approach.
>>
>> Images will only end up getting wrapped in anonymous blocks when they're
> in a block with other box children.  For example:
>
>  will cause the  to get wrapped in an
> anonymous block.
>
> This is due to he CSS rule that blocks may contain either all inline
> children OR all box/block children.  Thus since it has one block child (the
> ) the img has to get wrapped in an anymous block to keep with the rule.
> http://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level
>
>
>>
>>
>> Can any one please throw some light here & help us out.
>>
>> Thanks.
>>
>>
>>
>>
>> ___
>> 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] Question on Inline element

[Mustafizur Rahaman]

Hi All,

I was trying to develop my expertise by looking at some of the open issues &
I was looking 
intohttps://bugs.webkit.org/show_bug.cgi?id=22764.(Issue
with Windows build). We have done a preliminarily analysis & I want
to get little help so that we can proceed even further.

I have attached the source html & also the snapshot so that we can see the
issue.

The problem is because of the following line Subscribe

The paragraph element has all children inline (even though the image is
non-inline, but because it is a float/positioned object so it remains inline
element), as a result while doing the layout for the paragraph element, it
is only doing the layout for inline children.

Following code in RenderBlock::layoutBlock()
if (childrenInline())
layoutInlineChildren(relayoutChildren, repaintLogicalTop,
repaintLogicalBottom); ==>Control goes here
else
layoutBlockChildren(relayoutChildren, maxFloatLogicalBottom);

And then it goes to RenderBlock::createLineBoxesFromBidiRuns() where it is
only considering all the textual attributes (mainly font height which is 12
pixel), & not considering the image height which is greater than the text
height.

So my question is

   - Can a paragraph element contain an image element=> the html spec does
   not say NO.
   - If we make the image element neither float/nor positioned, it creates
   an anomynous block & everything is rendered properly. But I am not sure
   whether that is the right approach.

Can any one please throw some light here & help us out.

Thanks.





Some text here
  Subscribe


  

  



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