September 2010 - webkit-dev - lists.webkit.org

Fwd: Fwd: Fwd: HTML5 & MathML3 entities
by Alexey Proskuryakov 17 Sep '10

17 Sep '10

Начало переадресованного сообщения: > От: David Carlisle <davidc(a)nag.co.uk> > Дата: 17 сентября 2010 г. 15:32:45 Тихоокеанское летнее время > Кому: Alexey Proskuryakov <ap(a)webkit.org> > Тема: Ответ: [webkit-dev] Fwd: Fwd: HTML5 & MathML3 entities > > On 17/09/2010 22:57, Alexey Proskuryakov wrote: >> >> 17.09.2010, в 14:28, David Carlisle написал(а): >> >>> No the code point is in the math symbols block and was always >>> intended for math usage. Some time after the code point was added >>> (I think, I don't have the data to hand) it got added a canonical >>> mapping to to 3xxx block, that was an error that the unicode >>> consortium is now trying to correct (or at least back when unicode >>> 3.x added this new character) >> >> I cannot follow this argument. My understanding is that adding a >> single character canonical decomposition implies deprecation in >> Unicode, so describing this as a two-step process confuses me. > > adding a canonical decomposition doesn't imply deprecation. > Depending on which canonical form is chosen, the canonicalisation mapping can go either way, loosely speaking some forms prefer composite characters, some use combining characters in preference (not that combining characters are involved here) > > 2329 was deprecated some years after the canonical mapping was added > because it was realised that that mapping was wrong, but mappings are never changed once added. It became deprecated not when the mapping to 3008 was added; it became deprecated when it was replaced by 27E8 > I described it as a two step process because it happened in two stages. > > > >> At the time I looked at this (and also currently) the deprecated >> character had a canonical decomposition that made it equivalent to a >> CJK character. Any software that treats this character as a math one >> clearly violates many versions of the Unicode specs, including the >> current one. It might have been conformant to Unicode 2.0 or some >> earlier version though. > > It was conformant to unicode 2 yes, the fact that unicode then added a canonical form to 3xxx doesn't make them non conformant, systems don't have to use NFC form and they don't have to use any particular glyph, so for either reason it's perfectly conformant to use a math character for 2329. > >> >>> the lang and rang entity names come from the ISO math entity to >>> denote math angle brackets. These sets and these names predate >>> Unicode and predate HTML, it's unfortunate that after the names >>> were mapped to unicode a canonical mapping to a different character >>> was added, but >> >> I don't see how the origins of the debate change the fact that these >> Unicode fonts you mentioned violated the Unicode spec. They may have >> been doing "the right thing" or not, but arguing that they didn't >> violate the letter of the spec seems strange. > > I don't think they violate the spec at all. Except as far as the spec was internally inconsistent once it had added a canonical mapping between two separate characters. >> >> Clearly, I have a different perspective, since I don't think that >> things that pre-date HTML and Unicode should have much weight in >> today's decisions. > > The point is that there have been documents using those entities as math character names in continuous use since the '80s why should they all be broken? Not to mention the fact that the vast majority of use of those entities in html will also be expecting a mathematical bracket (even if on some systems, with some fonts the character glyph used was actually designed for CJK punctuation). > > In fact where classical ISO usage and HTML usage differed I followed HTML usage in all cases (for all the obvious reasons) even when the HTML definitions make no sense at all (eg asymp) but in this case > external factors (ie Unicode moving the goalposts) meant that the "new" Uniocde 3.2 character should be used here. > >> >>> the only fix the UTC suggest for that is just not using 2329 at all >>> and use 27E8 instead. Which is what the entity spec recommends. >> >> >> Did they actually suggest to use it for the lang entity in HTML, or >> did they suggest to use it when a math character is desired? > > xhtml entities have document scope it is not possible for an xhtml+mathml document to have different definitions for html and mathml use, but even for pure html use it is fairly clear that 27e8 is the correct choice. > > rang was never defined to be 3009, it was defined to be 232A and documented as being a math angle bracket. Unicode have deprecated 232A and suggest that any uses of that be replaced by 27E9 because 232A is effectively unusable as it is subject to an essentially accidental and incorrect normalisation to 3009. > > It would be bizarre in the extreme to redefine rang to be 3009 (is there any evidence of anyone ever having used that entity name and wanting a CJK character?) the choices are doing what Unicode has suggested (since Unicode 3.2) and using 27E9 instead, or the alternative would be to declare that changing the html entities is just too scary and to leave it as 232A and live with the fact that this will be inconsistently rendered, and violates the w3c/unicode charmod normal form rules, and is directly against the deprecation of this character in the Unicode specification. Of those two choices, defining it to be 27E9 seems to be the lesser of two evils. > > David > >> >> - WBR, Alexey Proskuryakov >> >> - WBR, Alexey Proskuryakov

1 0

Re: [webkit-dev] Fwd: Fwd: HTML5 & MathML3 entities
by Alexey Proskuryakov 17 Sep '10

17 Sep '10

17.09.2010, в 14:28, David Carlisle написал(а): > No the code point is in the math symbols block and was always intended > for math usage. Some time after the code point was added (I think, I > don't have the data to hand) it got added a canonical mapping to to 3xxx > block, that was an error that the unicode consortium is now trying to > correct (or at least back when unicode 3.x added this new character) I cannot follow this argument. My understanding is that adding a single character canonical decomposition implies deprecation in Unicode, so describing this as a two-step process confuses me. > > which was not very helpful.&rang used to be a synonym to U+232A, but > > now the former is a CJK character, and the latter is a math one. I > > think that consistency with Unicode consortium's choice is an > > important consideration. > > I think you have "former" and "latter" swapped in the above? Yes, sorry about that. They used to be synonyms, it hard not to get confused! > MathML did not violate any specs. Perhaps there can be different opinions about this :) At the time I looked at this (and also currently) the deprecated character had a canonical decomposition that made it equivalent to a CJK character. Any software that treats this character as a math one clearly violates many versions of the Unicode specs, including the current one. It might have been conformant to Unicode 2.0 or some earlier version though. > the lang and rang entity names come from the ISO math entity to denote > math angle brackets. These sets and these names predate Unicode and predate HTML, it's unfortunate that after the names were mapped to unicode a canonical mapping to a different character was added, but I don't see how the origins of the debate change the fact that these Unicode fonts you mentioned violated the Unicode spec. They may have been doing "the right thing" or not, but arguing that they didn't violate the letter of the spec seems strange. Clearly, I have a different perspective, since I don't think that things that pre-date HTML and Unicode should have much weight in today's decisions. > the only fix the UTC suggest for that is just not using 2329 at all and use 27E8 instead. Which is what the entity spec recommends. Did they actually suggest to use it for the lang entity in HTML, or did they suggest to use it when a math character is desired? - WBR, Alexey Proskuryakov

1 0

Fwd: Fwd: Fwd: HTML5 & MathML3 entities
by Alexey Proskuryakov 17 Sep '10

17 Sep '10

Начало переадресованного сообщения: > От: David Carlisle <davidc(a)nag.co.uk> > Дата: 17 сентября 2010 г. 14:28:33 Тихоокеанское летнее время > Кому: Alexey Proskuryakov <ap(a)webkit.org> > Тема: Ответ: [webkit-dev] Fwd: Fwd: HTML5 & MathML3 entities > > On 17/09/2010 21:12, Alexey Proskuryakov wrote: >> >> 17.09.2010, в 12:49, Alexey Proskuryakov написал(а): >> >>> math fonts in uniocde layout typically use the opposite choice for >>> the old character, and math renderers (including if I remember >>> correctly mozilla's original mathml support) that map unicode slots >>> to "legacy" 8 bit math font encodings (eg the TeX or mathematica >>> fonts) also rendered these things to match the math operators. >> >> I'd say that this was a misuse of the character point, > > No the code point is in the math symbols block and was always intended > for math usage. Some time after the code point was added (I think, I > don't have the data to hand) it got added a canonical mapping to to 3xxx > block, that was an error that the unicode consortium is now trying to > correct (or at least back when unicode 3.x added this new character) > >> and thus a bug in the font. Unicode fonts aren't supposed to use > glyphs with different meanings in the same code points (although some > may claim that CJK unification crosses the border in that respect). >> >>> So given, as you say, that some change was inevitable, taking the >>> math choice is I still think the right one >> >> >> It just seems that Unicode consortium and W3C basically decided to >> make opposite choices on this, > > No the change was explicitly at the suggestion of the UTC who wanted to > deprecate the use of the old character and clarify that (because the > character was always intended for math use) that any uses of the old one > are replaced by the new one, > > > which was not very helpful.&rang used to be a synonym to U+232A, but > now the former is a CJK character, and the latter is a math one. I > > think that consistency with Unicode consortium's choice is an > > important consideration. > > I think you have "former" and "latter" swapped in the above? > > &rang used to map to 232A which was originally a math character but then erroneously given a canonical mapping to 3009 > > It now maps to 27E9; which was a character added by the UTC explicitly > to be a replacement for the deprecated 232A, which is only deprecated because it had been given an erroneous NFC mapping, > > As I said above the definition as given in the spec _is_ the choice of the Unicode consortium (or at least the choice of those members of the UTC who corresponded with me) >> > >> But if I understood you correctly, there is a significant amount of >> MathML documents that use rang/lang, is that accurate? > > Oh yes angle brackets are very common notation. > > > Practical compatibility requirements are more important than potential > > issues that I cited, at least as long as they remain potential. If I > > had an example of brokenness, > > > I'd say that HTML content that followed specs outweighs MathML content > > that violated them. > > MathML did not violate any specs. > > the lang and rang entity names come from the ISO math entity to denote > math angle brackets. These sets and these names predate Unicode and predate HTML, it's unfortunate that after the names were mapped to unicode a canonical mapping to a different character was added, but the only fix the UTC suggest for that is just not using 2329 at all and use 27E8 instead. Which is what the entity spec recommends. >> >> - WBR, Alexey Proskuryakov >> >> > David - WBR, Alexey Proskuryakov

1 0

Fwd: Fwd: HTML5 & MathML3 entities
by Alexey Proskuryakov 17 Sep '10

17 Sep '10

> От: David Carlisle <davidc(a)nag.co.uk> > Дата: 17 сентября 2010 г. 12:39:56 Тихоокеанское летнее время > Кому: Alexey Proskuryakov <ap(a)webkit.org> > Тема: Ответ: [webkit-dev] Fwd: HTML5 & MathML3 entities > > On 17/09/2010 19:58, Alexey Proskuryakov wrote: > the list is closed to non subscribers, could you forward, thanks, >> >> This certainly sounds like it was a mistake originally, but in practice, >> this meant that &rang; and &lang; were rendered as CJK characters by >> browsers. U+27E8 looks differently (and is possibly treated differently >> by screen readers), and it's this change in behavior that I find >> unfortunate. > > well (as you'll be aware) what the glyph looks like depends on what fonts used. general text fonts (that are supporting the CJK ranges) would have this effect but math fonts in uniocde layout typically use the opposite choice for the old character, and math renderers (including if I remember correctly mozilla's original mathml support) that map unicode slots to "legacy" 8 bit math font encodings (eg the TeX or mathematica fonts) also rendered these things to match the math operators. lang and rang names were clearly originally intended to mean > left and right math angle brackets, coming from the ISO math entity sets. So given, as you say, that some change was inevitable, taking the math choice is I still think the right one, although any change has some costs, I agree. > > David > - WBR, Alexey Proskuryakov

2 4

Fwd: HTML5 & MathML3 entities
by Maciej Stachowiak 17 Sep '10

17 Sep '10

Forwarding this because it apparently didn't make it to the list. Begin forwarded message: > From: David Carlisle <davidc(a)nag.co.uk> > Date: September 17, 2010 8:44:51 AM PDT > To: webkit-dev(a)lists.webkit.org > Cc: mjs(a)apple.com > Subject: Re: [webkit-dev] HTML5 & MathML3 entities > > Not sure I can post to this list (hence cc to Maciej) but replying to the thread from July > > http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg11986.html > > there were a couple of points raised. > > * that rang changed definition > > and > > * entities expanding to more than once character not being supported. > > On the first: > > rang did not used to be (directly) a CJK character it was in the math symbol block at 2329 but erroneously given a canonical decomposition to the CJK block at 3008. Unicode recognised the error but never change canonical decompositions so they deprecated 2320 and introduced a new character 27E8 that is the same apart from this decomposition. > > http://www.unicode.org/charts/PDF/U2300.pdf > > explicitly says these characters are deprecated: > > > Also, even if Unicode had not deprecated 2329, the W3C "Unicode Normal Form" bans entities using characters that have canonical decompositions as it makes entity expansion and NFC canonicalisation interact badly. Changing the definition is unfortunate but sort of inevitable given the history. > > > On the second: > It's probably worth noting that currently the HTML5 spec only lists entities that expand to a single character, but there is an open bug entry about that: > > http://www.w3.org/Bugs/Public/show_bug.cgi?id=10067 > > David > > > > > > ________________________________________________________________________ > The Numerical Algorithms Group Ltd is a company registered in England > and Wales with company number 1249803. The registered office is: > Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. > > This e-mail has been scanned for all viruses by Star. The service is > powered by MessageLabs. ________________________________________________________________________

2 1

Re: [webkit-dev] Review tool changes
by Ryosuke Niwa 17 Sep '10

17 Sep '10

On Thu, Sep 16, 2010 at 6:48 PM, Maciej Stachowiak <mjs(a)apple.com> wrote: > On Sep 16, 2010, at 6:25 PM, Ojan Vafai wrote: > > On Fri, Sep 17, 2010 at 10:33 AM, Darin Adler <darin(a)apple.com> wrote: > >> 2) It’s kind of crazy that the review tool’s URL is >> "...&action=prettypatch". It was nice of you to leave the old review tool >> unchanged, at least in part to placate me, but you’re squatting on another >> feature’s territory! I think we want a plain old formatted diff for other >> purposes. We need to get your tool out of there! >> > > What's crazy about this? What are the other uses of the plain formatted > diff that aren't met by this? I agree with the new tool replacing the old > one. I just don't see the benefits of keeping both the new review tool and > the formatted diff page. > > Sometimes you just want a formatted view of the patch. To give one example, > Cmd+A Cmd+V does not do the right thing on this page for someone who just > wants the patch. > Yeah I often use that to get a part of patch that I posted on bugzilla. e.g. I post some work in progress in bugzilla but decide to change my approach. But I can still make a use of some changes in my original patch, so I just copy & paste from pretty diff and then remove line numbers on TextMate and paste it on XCode. (Let me know if there's a better way of doing this sort of stuff). I do really like the layout of the new page. Seems like it will be really > good for reviews. (Maybe the "Publish" button should be labeled "Preview" to > reduce needless nervousness.) > I second that. - Ryosuke

1 0

Blob scheme implementation
by Adam Barth 16 Sep '10

16 Sep '10

Jian Li just had a conversation in #webkit about where the code for implementing the Blob URL scheme should live. I thought I'd open the discussion to webkit-dev in case folks had a different perspective. As part of the fileapi, we're introducing a new URL scheme, called blob, which represents a bucket of bits, usually from a file, but potentially from another location. Assigning these objects URL is helpful because then they integrate with the rest of the web platform. For example, you can use them as images via the <img> element or videos via the <video> element, etc. Currently, the blob URL scheme is implemented with a subclass of ResourceHandle (our primary network abstraction) called BlobResourceHandle. My sense is that this isn't the right place in the architecture to add support for the blob URL scheme. The issue is that each port has a table somewhere that maps URL schemes to networking backends. In Chromium, for example, that mapping is provided by URLRequestFactory, which lives in the "net" module. By implementing the blob URL scheme at the ResourceHandle layer, we're short-circuiting that table. In some sense, this is analogous to adding an HTTPResourceHandle and implementing the HTTP protocol inside of WebCore. While its true that most (all?) users of WebKit will need to wire WebCore up to an HTTP library, that doesn't necessarily mean that WebCore should contain an implementation of the HTTP protocol. In the same way, even if a large number of WebKit users will wish to support the blob URL scheme, that doesn't necessarily mean that WebCore should contain an implementation of the scheme. I can certainly see the appeal of sharing the blob URL implementation code between different ports of WebKit, but we can achieve that goal in a number of ways, including creating an external library or a separate BlobCore module. Adam

8 26

Can node->renderer()->node() == node ever be false?
by Dimitri Glazkov 15 Sep '10

15 Sep '10

Dear WebKit, I've been looking at this line here and it doesn't seem to make sense to me: http://trac.webkit.org/browser/trunk/WebCore/page/EventHandler.cpp#L2153 It looks like the loop in question will always exit early, because it short-circuits to node->renderer()->node() == node, which seems like it always will be true. At least, that's what the layout tests say when I remove it. The loop was added here: http://trac.webkit.org/changeset/25057/trunk/WebCore/page/EventHandler.cpp Can the elders and the wizards of WebKit shine the light upon my forehead and provide me with the mirth of understanding? :DG<

3 6

Re: [webkit-dev] hey man
by leslie.lg＠hotmail.com 15 Sep '10

15 Sep '10

hey, I never see you around anymore, I feel like you're always busy wth work. Anyway: maybe this will cheer you up. I found a news article that describes in detail ways you can make some extra money. It's easier than it sounds You should really check out this news article they wrote - <a href="http://cru.ms/943e85">Look over the article here</a>

1 0

Build.webkit.org Downtime: Tomorrow, Sep 15, 8am PDT
by William Siegrist 15 Sep '10

15 Sep '10

Build.webkit.org will be down tomorrow for a software upgrade starting around 8am PDT. Total downtime should be less than 1 hour. This is fairly short notice, so I apologize for that, but we're trying to fix the performance issues we've been experiencing. You may have trouble running webkit-patch while build.webkit.org is down, but that is covered by <https://bugs.webkit.org/show_bug.cgi?id=45707>. If you find problems with anything after build.webkit.org is back up, please let me know as soon as possible and cc me on the bug. Thanks -Bill

1 1