Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules
On Tuesday, July 8, 2014 3:34:50 AM UTC+10, ian.h...@gmail.com wrote: On Tuesday, July 1, 2014 12:58:45 PM UTC-7, Koji Ishii wrote: Summary: Two recent HTML changes improve ruby support: 1) Addition of the rb and rtc elements (but not rbc); and 2) Matching update to the tag omission rules to make ruby authoring easier. By implementing these changes, Gecko supports the parsing side of all the ruby use cases required for the internationalization of HTML (see use cases document below for details). It also enables the implementation of the CSS Ruby Layout. The Japanese education market strongly requires this and a Mozilla developer has already started working on it. Could you elaborate on why we are using the more complicated W3C rules here instead of the simpler WHATWG rules, given that the WHATWG rules also address the same use cases? IMO, the main reason is that, the W3C rules provide more flexibility for authors to make the document more semantic and stylable. Please note that, the inline form is not limited to providing compatibility. You can see an example in JLREQ Fig. 3.9. It is a use case includes inline kana. If you want the word 明朝体 to be marked in ruby in separate form, with the WHATWG rules, you must write it as: ruby明rtみん/rt朝rtちょう/rt体rtたい/rt/ruby It is incompatible with the inline form, which means, if an author wants to switch between the inline form and ruby, there are only two options: 1. provide a different document for each form; 2. drop the separate form and use only the collapsed form for ruby. Neither of them perfectly matches the requirement. But with the W3C rules, it can be written as: rubyrb明rb朝rb体rp（rtみんrtちょうrtたいrp）/ruby which is obviously compatible with the inline form. The difference in expression ability becomes more important when there are words mixed with kanji and kana, such as 振り仮名. For this word, you won't even have the second option above, because I don't think people want to write something like ruby振り仮名rtふりがな/rt/ruby In conclusion, I think the WHATWG rules are not flexible enough for multi-pair rubies, which limits both the semantization and the stylability of documents. In other words, I don't think the two rule sets address the same use cases, especially in perspective of semantics. The W3C rules are much more powerful, though also more complicated, than the WHATWG rules. - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On Mon, Dec 22, 2014 at 11:10 PM, Jeff Muizelaar jmuizel...@mozilla.com wrote: Possible solutions would be to: - remove implicit conversions to T* If this were done, I think we should change the calling convention for functions that take pointers to refcounted classes. The convention is broken anyway: the convention is supposed to be that the caller holds a strong reference, but the parameter type is a raw pointer, which does not enforce this. This has led to at least one sec-critical that I know of, IIRC, where the caller did not hold a strong reference locally, and the callee wound up freeing it. There have probably been lots more that I don't know of. I've thought in the past of a RefParamT type, which would be for use only as a function parameter. nsRefPtrT/nsCOMPtrT would implicitly convert to it, but raw pointers would not implicitly convert to it. And it would implicitly convert to a raw pointer, which is safe as long as the nsRefPtrT/nsCOMPtrT that it was initialized with was a local variable (and not a member or global). Thus to the callee, it would behave exactly like a raw pointer. The only difference is the caller is not allowed to pass a raw pointer. With this change, we wouldn't need to convert from nsRefPtrT to T* often, as far as I can think of. It would also preserve binary compatibility with XPCOM AFAICT, because RefParamT would have trivial constructor and destructor and no virtual functions. It also would add no addref/release. It would just help the compiler catch cases where raw pointers are being passed to functions that expect the caller to hold a strong reference, which would perhaps allow us to sanely remove the implicit conversion from nsRefPtrT to T*. - add operator T* explicit and operator T* = delete // this will be available in GCC 4.8.1 and MSVC 2014 Nov CTP What would this do? I see that deleting operator T* would prevent a temporary nsRefPtrT from converting unsafely to a raw pointer, which would address that objection to removing already_AddRefed. But what does the first part do? On Tue, Dec 23, 2014 at 1:21 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Are there good use cases for having functions accept an nsRefPtrT? If not, we can outlaw them. Do we have a better convention for an in/out parameter that's a pointer to a refcounted class? editor uses this convention in a number of functions for pass me a node/pointer pair as input, and I'll update it to the new value while I'm at it. If there's a good substitute for this, let me know and I'll use it in the future when cleaning up editor code. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules
Hi Xidorn, Xidorn Quan quanxunz...@gmail.com, 2014-12-26 04:41 -0800: ... If you want the word 明朝体 to be marked in ruby in separate form, with the WHATWG rules, you must write it as: ruby明rtみん/rt朝rtちょう/rt体rtたい/rt/ruby It is incompatible with the inline form, which means, if an author wants to switch between the inline form and ruby, there are only two options: 1. provide a different document for each form; 2. drop the separate form and use only the collapsed form for ruby. Neither of them perfectly matches the requirement. But with the W3C rules, it can be written as: rubyrb明rb朝rb体rp（rtみんrtちょうrtたいrp）/ruby which is obviously compatible with the inline form. The difference in expression ability becomes more important when there are words mixed with kanji and kana, such as 振り仮名. For this word, you won't even have the second option above, because I don't think people want to write something like ruby振り仮名rtふりがな/rt/ruby What would be the right way to mark that up with rb? In particular, what would be the right way if the authors wants to switch between the inline form and ruby? --Mike In conclusion, I think the WHATWG rules are not flexible enough for multi-pair rubies, which limits both the semantization and the stylability of documents. In other words, I don't think the two rule sets address the same use cases, especially in perspective of semantics. The W3C rules are much more powerful, though also more complicated, than the WHATWG rules. -- Michael[tm] Smith https://people.w3.org/mike signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Usefulness of JS strict warnings? (Branched from: Is anyone still using JS strict warnings?)
On a side note here, is there any usefulness of fixing these warnings (more specifically in web content than chrome content)? If you use any JS libraries like jQuery, they tend to spew a lot of these warnings. But take for example this code: s = Some text; console.log(s); With javascript.options.strict set to true, it outputs ReferenceError: assignment to undeclared variable s. Are there any advantages to actually fixing it? The code obviously works just fine either way. Wesley Hardman On 2014-12-19 15:19, Jason Orendorff wrote: So if you go to about:config and set the javascript.options.strict pref, you'll get warnings about accessing undefined properties. js Math.TAU undefined /!\ ReferenceError: reference to undefined property Math.TAU (It says ReferenceError, but your code still runs normally; it really is just a warning.) Is anyone using this? Bug 1113380 points out that the rules about what kind of code can cause a warning are a little weird (on purpose, I think). Maybe it's time to retire this feature. https://bugzilla.mozilla.org/show_bug.cgi?id=1113380 Please speak up now, if you're still using it! -j ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Usefulness of JS strict warnings? (Branched from: Is anyone still using JS strict warnings?)
On 12/26/2014 07:24 AM, Wesley Hardman wrote: s = Some text; console.log(s); With javascript.options.strict set to true, it outputs ReferenceError: assignment to undeclared variable s. Are there any advantages to actually fixing it? The code obviously works just fine either way. It's trivial to put a var in front of this. Declaring global variables may make code run faster. In this super-limited example, maybe not. But teaching when it's faster and when it's not is far less easy than a simple blanket rule to create global variables using declarations. In general that's how most of the extra-warnings warnings work -- don't do it this way, because this way can be bad, although we're not going to conclusively say it's not bad in this exact instance because that requires expert human confirmation. Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Is anyone still using JS strict warnings?
On 12/22/2014 08:08 AM, Paolo Amadini wrote: Maybe we could make available an opt-in code linting solution - and these typos would become errors, not warnings, One substantial problem from a JS engine point of view is that we're implementing a specification. That specification says these behaviors are not errors (let alone early errors that prevent script execution overall). Introducing our own proprietary version of JS with these as errors creates a purely self-inflicted language, that we are not going to sufficiently document to actively support it -- if we even wanted to support it, which I don't think we do because this isn't The Open Web. Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On 12/26/2014 03:08 PM, Aryeh Gregor wrote: On Mon, Dec 22, 2014 at 11:10 PM, Jeff Muizelaar jmuizel...@mozilla.com wrote: Possible solutions would be to: - remove implicit conversions to T* If this were done, I think we should change the calling convention for functions that take pointers to refcounted classes. The convention is broken anyway: the convention is supposed to be that the caller holds a strong reference, but the parameter type is a raw pointer, which does not enforce this. This has led to at least one sec-critical that I know of, IIRC, where the caller did not hold a strong reference locally, and the callee wound up freeing it. There have probably been lots more that I don't know of. I've thought in the past of a RefParamT type, which would be for use only as a function parameter. nsRefPtrT/nsCOMPtrT would implicitly convert to it, but raw pointers would not implicitly convert to it. And it would implicitly convert to a raw pointer, which is safe as long as the nsRefPtrT/nsCOMPtrT that it was initialized with was a local variable (and not a member or global). Thus to the callee, it would behave exactly like a raw pointer. The only difference is the caller is not allowed to pass a raw pointer. With this change, we wouldn't need to convert from nsRefPtrT to T* often, as far as I can think of. It would also preserve binary compatibility with XPCOM AFAICT, because RefParamT would have trivial constructor and destructor and no virtual functions. It also would add no addref/release. It would just help the compiler catch cases where raw pointers are being passed to functions that expect the caller to hold a strong reference, which would perhaps allow us to sanely remove the implicit conversion from nsRefPtrT to T*. How would this setup help with the case when one passes nsCOMPtr/nsRefPtr member variable as a param? I believe that has been the most common issue with caller-should-keep-the-parameter-alive - one just doesn't remember to make sure the value of the member variable can't be replaced with some other value while calling the method. - add operator T* explicit and operator T* = delete // this will be available in GCC 4.8.1 and MSVC 2014 Nov CTP What would this do? I see that deleting operator T* would prevent a temporary nsRefPtrT from converting unsafely to a raw pointer, which would address that objection to removing already_AddRefed. But what does the first part do? On Tue, Dec 23, 2014 at 1:21 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Are there good use cases for having functions accept an nsRefPtrT? If not, we can outlaw them. Do we have a better convention for an in/out parameter that's a pointer to a refcounted class? editor uses this convention in a number of functions for pass me a node/pointer pair as input, and I'll update it to the new value while I'm at it. If there's a good substitute for this, let me know and I'll use it in the future when cleaning up editor code. nsCOM/RefPtr is a good option for inouts. (Tough one should avoid inouts when possible.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules
On Sat, Dec 27, 2014 at 12:23 AM, Michael[tm] Smith m...@w3.org wrote: Hi Xidorn, Xidorn Quan quanxunz...@gmail.com, 2014-12-26 04:41 -0800: ... If you want the word 明朝体 to be marked in ruby in separate form, with the WHATWG rules, you must write it as: ruby明rtみん/rt朝rtちょう/rt体rtたい/rt/ruby It is incompatible with the inline form, which means, if an author wants to switch between the inline form and ruby, there are only two options: 1. provide a different document for each form; 2. drop the separate form and use only the collapsed form for ruby. Neither of them perfectly matches the requirement. But with the W3C rules, it can be written as: rubyrb明rb朝rb体rp（rtみんrtちょうrtたいrp）/ruby which is obviously compatible with the inline form. The difference in expression ability becomes more important when there are words mixed with kanji and kana, such as 振り仮名. For this word, you won't even have the second option above, because I don't think people want to write something like ruby振り仮名rtふりがな/rt/ruby What would be the right way to mark that up with rb? In particular, what would be the right way if the authors wants to switch between the inline form and ruby? It would be rubyrb振rbりrb仮rb名rtふrtりrtがrtな/ruby The rt for り here could be individually hidden in ruby form by stylesheets. In fact, in CSS Ruby, we currently have autohide rule which automatically hide the the annotation when it is equal to the base. - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Flaky timeouts in mochitest-plain now fail newly added tests
On Fri, 19 Dec 2014 18:58:53 -0500, Ehsan Akhgari wrote: On 2014-12-19 4:40 PM, Nils Ohlmeier wrote: On Dec 19, 2014, at 6:56 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Logging sufficiently is almost always enough to not have to use these timers, as those tests have demonstrated in practice. I disagree. Especially as the logging of mochitest is really poor. - the timestamps of log messages are lost as described in bug 1020516 - SimpleTest only has one log level: info(). Which I think is the main reason the log files get big, because test writers can’t fine tune the logging. - Log messages from mochitest are not printed together with the stdout/stderr of the browser (so correlating these two is almost impossible) - Logging behaves differently on your local machine then on the build servers Some of these (such as the latter two) seem to be issues that you'd also have with your own custom logging in mochitest, so I'm not sure how the timer based logging is not affected by them. I assume multiple custom timers can provide different output that can support a diagnosis without timestamps. BTW I understand that WebRTC has pretty special and probably unique requirements, compared to what the rest of the mochitest users do with it. FWIW, these issue plague test result analysis in general, not just rtc. But thinking of this more, do you find it useful to be able to register a callback with the harness to be called when the harness decides to kill your test because it has timed out? (Obviously the callback would be informational, and would not be able to prevent the harness from killing the test and moving on.) That might be useful, but perhaps it would not be necessary if logging worked. Perhaps it is better to have an error handler that only runs when there are errors, reducing spam, but that means keeping disjoint parts of the test in sync perhaps putting more state in global scope, while logging is simple to maintain. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On Tue, Dec 23, 2014 at 1:21 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Are there good use cases for having functions accept an nsRefPtrT? If not, we can outlaw them. Aryeh Gregor writes: Do we have a better convention for an in/out parameter that's a pointer to a refcounted class? editor uses this convention in a number of functions for pass me a node/pointer pair as input, and I'll update it to the new value while I'm at it. If there's a good substitute for this, let me know and I'll use it in the future when cleaning up editor code. nsRefPtrT* ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
